打算重新开始写点东西。
持续性（Consistency）
大学的时候，大家喜欢在考前突击复习。由于宿舍熄灯，包括我在内的很多人都选择去学校附近的咖啡馆刷夜。这对短期高强度工作的偏好在我开始工作后依然存在。比如某一天睡不着，我可能会直接起来工作到两三点，然后第二天下午再去上班。
然而最近两年我逐渐意识到，虽然突击可以带来短期的高效，从长期来看，效果却不如保持稳定的节奏，持续输出。那么怎样算是拥有持续性？我很喜欢 Sahil 的这组推文中的例子，虽然他讲的 two-day rule 并不是这里讨论的重点。以工作为例，严格地每天八点起，五点下班，这当然是一种 consistency；但如果你早上十点起，晚上加班，这同样是 consistency。又或者，选择每周加两天班，其它时间正常下班。我觉得关键在于找到一种自己舒服的节奏，可以是以天、周，甚至两周为单位，不要去打破它。
从纯粹个人的经验看，持续性可以为制定计划提供依据，比如让你更好地估计某项任务要花久完成。另一方面，它极大地减少了“低能量时期”的出现。过去，我会不定期地有几天什么都不想干，不要说工作和运动，甚至连游戏都不想打——个人把它称作“低能量时期”。不知道大家是否有这种情况。一旦处于这种状态，我基本只能躺着看手机，别的什么都做不了。一度我甚至怀疑自己是不是有抑郁症。但最近两年，这种情况出现得越来越少。我无法完全肯定（毕竟这不是科学实验），但认为它和持续性的工作状态相关。这方面我不懂所以如果说错请指出，但我猜测生活节奏的起伏（比如某几天突然熬夜）会打破身体里的某种平衡（比如激素分泌、节律、代谢），从而导致异常状态。
睡眠
直接引用以前的推文好了。有很多因素会影响工作和生活的质量，但如果你问我哪一点最重要，我一定会说是睡眠。
马竞球星略伦特3万英镑买床垫：为了比赛，钱花得值！
当初看到这个新闻时只觉得好玩，但真的买了个稍微好点的床垫，我才意识到这一点都不夸张。当然，我买不起那么贵的：）
Complexity of life
之前看到 Jordan Peterson 的一个视频，很有感触（注：不代表同意他的所有观点）。
人们的生活太过复杂，以至于他们宁愿选择死亡。他们通过自杀寻求死亡是为了结束复杂。因为这种复杂一旦失控，就导致痛苦。
The Heat around PyPI "critical" Packages
Recently, PyPI mandates 2FA for critical projects, but got many push backs from developers (1, 2). Many people (assuming open source project maintainers) don't like the idea of being forced to put more work into projects they don't get paid to work on.
Armin Ronacher (creator of Flask, Sentry) discussed this in more detail, suggesting there's a better way like cargo-vet than putting more burden on maintainers. Donald Stufft (Python core dev, pip/PyPI maintainer) on the other hand, believes that maintainers do have certain responsibilities.
While almost all people agree that enforcing 2FA is a sensible move, I think the real problem is still about the responsibility of open source software (OSS) maintainers, or, does it even exist?
The Responsibility of OSS Maintainers
Many OSS maintainers complained on Twitter that they've been seen by users and big companies as "free labor", like the one Daniel Stenberg (creator of curl) posted.
Despite all the posts, it seems like we're entering a dead end: users keep asking, and maintainers keep clarifying. The OSS community has wasted so much time and energy on this, and it makes me wonder whether we're trying to solve the right problem. "How many responsibilities do OSS maintainers have?", it doesn't even feel possible to have a right answer, because projects are so different by themselves.
I think, the question we need to answer is:
For a specific project, how to get its maintainers and users to reach a consensus on the responsibilities of maintainers?
The differences with the original question are:
- Target projects individually, instead of viewing them as a whole.
- Involves both sides, instead of only one.
- Building an understanding is always the foundation towards more actions.
A Possible Solution
Naturally, we think of a similar thing: open-source licenses. It's answering the opposite question: what are OSS users allowed to do? What if, we have something similar for maintainers, and let's just call it "software maintainer commitment", or SMC.
Suppose we have something like this, what will it look like?
- For 90% of the projects, they will remain as is, i.e. no commitment. This means maintainers have absolutely no responsibility.
- For some, they're willing to enable 2FA to provide the least assurance. Some may be willing to ensure compatibility with the latest version of the language it's written in.
For projects maintained by big companies, that's a whole different story. I can imagine big companies have the resources to provide a long list of commitments, and they're willing to do so to attract more users. This is certainly unfair for maintainers working in their free time, but on the other hand, by making the distinction clear that there are different levels of commitment, users will no longer assume that each project can provide the support that they imagine, which is the whole point of SMC.
Though the idea comes from OSS licenses, implementation wise, SMC will be different in many ways:
- There will no longer be pre-defined commitments like MIT, GPL, except "no commitment", which is like WTFPL.
- Commitments need to:
- Be fine-grained: support the attributes that maintainers may need to specify, and allow expansion.
- Be configurable: commitment is often more than just "yes" or "no". For example, one might say I guarantee to fix security issues in x days, and x can be an arbitrary integer greater than 0.
- Allow anti-commitment: since all we want is to bring more clarity, anti-commitment makes total sense. An extreme case would be: as a maintainer, I will not fix any issues, and it's the users' responsibility to do so.
- Allow conditional commitment: Often times, financial support is critical to keeping a project alive. Things like GitHub sponsors and Open Collective have helped many developers and made many projects better maintained. SMC should allow developers to state "if you pay me $500, I will respond to your bug in x days and make it a higher priority."
In short, commitments need to be a lot more flexible than licenses, because maintainers have different needs.
A Beautiful Future and a Bumpy Road
So what can we do with software maintainer commitment (assuming it's widely adopted and recognized)?
- It makes maintainers happier, and users less confused.
- It saves people's time, for both maintainers and users: less questioning, arguing, clarifying, complaining. We're talking about the time people spend on communication, and that's a lot of time.
- It helps users select the projects to depend on.
- It helps identify the risk in your supply chain. Remember this graph?
But how are we going to analyze all these arbitrary commitments, you might ask? Well, that's where machine learning can help.
The future sounds fantastic, but to get there we need to go through a bumpy road, and I'm not even sure we can.
- Unlike a license that is backed by legal precedent, SMC doesn't really "enforce" anything. Stating a high support level doesn't mean a project is actually supported. On the contrary, if somehow it is enforced by law, then maintainers will not use commitment for sure because the risk is too high.
- Most maintainers probably just don't care about having such a thing.
- Creating commitments by themselves is not enough, having them widely recognized and respected is as important. This is really hard and will probably take decades.
With all the difficulties, I never doubt the value of transparency and clarity. Again, it's worth noting that the purpose of software maintainer commitment is not to encourage maintainers to do more things, but to resolve the confusion around responsibility. I can imagine that personal maintainers tend to have mostly anti-commitments, while corporations will have more commitments. This is fine, and if we get there, the world of open source will be a lot better than today.
The World Is Different Now
The world has become very different. In 2011, it's still Why Software Is Eating the World. Today, can you imagine an article like this that does not even mention open source? Open source is not new, but in the past, it was not as critical as it is today that affects almost every aspect of human beings. The scale of users has made OSS beyond just a topic among hackers. The atmosphere also changed with it, there's no "common sense" any more. With the explosive expansion of OSS, the management and ideology of open source is falling behind.
With or without software maintainer commitment, the issue of maintainer responsibility has to be solved. I have faith in human, and we'll get there eventually.
Appendix
James Bennett wrote an article that mentions similar ideas.
This blogpost describes the Python development setup that makes the most sense to me (and probably you as well) in 2022 and beyond. By "Development Setup", I mean the local development environment, and not about deploying apps on a server.
The Best Setup, in A Nutshell
- For executables/utility tools (e.g. mypy, black), install with system Python + pipx
- For project development, install different Python versions via pyenv
- For dependency management, use PDM (PDM is installed via pipx)
I'll explain each choice in more details below.
Why Use Both System Python and Pyenv Python?
One unusual thing you probably have noticed is that the setup consists of two ways to install Python: the system Python and Python installed by pyenv. Here, by "system Python", I mean the Python carried with your system, or the Python installed with a system package manager (e.g. apt, brew). Many articles suggested that we should never using system Python, so why still use it? Because we need two independent systems for two different purposes:
- For utility tools, reliability matters the most. You want them to always work when you need them. The less things they depend on, the better. System Python is the best choice, because they have the least dependencies. Also, for utility tools, It doesn't really matter which Python it is running on. Therefore even if system Python is behind the latest version, it is usually fine.
- For Python interpreters used by projects, flexibility is more important. You may need to upgrade them when a patch version fixed a bug, or using a specific Python version because that's what you have on the server. pyenv fits this purpose well.
pipx
pipx needs no introduction, it has become the de-facto way to install Python executables. But imagine if you install pipx with pyenv-installed Python. This creates a dependency like this:
mypy --> pipx --> 3.9.7 (pyenv) --> pyenv --> system Python
As you can see, the 3.9.7 (pyenv) --> pyenv part is unnecessary. It also creates trouble when upgrading Python: you either have to reinstall pipx, or keep Python 3.9.7 forever since pipx and all the tools above relies on it.
PDM
Now comes to the controversial part: PDM. Disclaimer: PDM is my personal choice, and it's totally ok if you chose Poetry, Pipenv, or any other tools. Here are the reasons why I use PDM:
⚠️⚠️ UPDATE 2023.5: I should clarify that, PEP 582 is good for developing libraries; for applications, PDM's virtualenv mode should still be preferred.
PDM helped me get away from virtual environments
I used to have 10+ virtual environments, and I get a headache every time I saw the long list. It essentially makes it impossible to ever upgrade my project Python, because I really don't want to setup virtual environments again for every project.
With PDM, I have no virtual environments. Each project directly depends on the pyenv-installed Python. I'm also free to upgrade patch versions (e.g. from 3.9.7 to 3.9.9), which allow me to always use the latest Python release.
See also You don't really need a virtualenv.
PDM is well maintained
PDM is created and maintained by PyPA member Frost Ming. If you don't know what PyPA members do, let's just say they know the best about Python packaging. Frost Ming also maintains Pipenv.
I used to use Poetry, which is also a nice tool. But sometimes Poetry is buggy, especially when upgrading project Python. What's worse is that no one seems to be dealing with those bugs (example). PDM is the opposite. Issues are usually responded within a day or two, including feature requests.
Benefit from being maintained by a PyPA member, PDM is usually the fastest in adopting new proposals in the Python packaging world, which lets its users stay on high productivity.
Overall, I find PDM better than other tools I've used, and it's constantly getting better (5~6 releases per month). I tweeted about my transition from Poetry to PDM, might be interesting to read.
Caveats
You may still need to install a new system Python when the old version gets deprecated. You can use pipx reinstall-all to reinstall existing tools, which is not so bad.
The setup may or may not work on Windows. If you can confirm which case it is, and/or if there's any issues, let me know, I'm happy to put them in the article.
Summary
In the past few years, Python gained a lot of great improvements in the development/packaging ecosystem, but this also created a mess that even the most experienced developers had a hard time picking tools. Luckily, I've found the silver bullet that works for me, and I hope it would also work for you.
