uv is its own thing, but direnv + `source .venv/bin/activate` is straightforward nowadays.
Direnv has saved me so much pain nowadays
Direnv has saved me so much pain nowadays
`layout python` is great when that just works. I have trouble juggling various Python version effectively with direnv's layout script (I _know_ I'm doing something wrong, but I can just set up a virtual env as a one time operation so...)
(I also like sourcing bceause I know _exactly_ what's happening, as I know more about the activation scripts than the layout script direnv provides. But that's just a personal thing)
Pipenv doesn't automatically activate the venv on entry into a shell. But a shell plugin named pipenv-activate supports this. It does what you use direnv for in this case, without an envrc file in the source.
One major difference of pipenv from vanilla venv is that pipenv creates the venv in a common location outside the project (like poetry does). But this shouldn't be a big problem, since you wouldn't commit the venv into VCS anyway.
Rust programmers seem to be lousy with ECS frameworks that never get used in any games but seem hell bent on proving that rust is the best language for game programming, and python programmers seem to break out in a case of "packaging tool building". I don't know what causes this. Perhaps some sort of pathological thinking that "I can do better"?
I really like python (and I like rust too), but if I were to take an honest look at the python packaging and environment ecosystem, I'd think that I'm being trolled. I lived through the age of setuptools.py, and while it was not good, at least there was only one approach really. Now we have a bazillion approaches that are all good, and zero consensus on what to use. Each individual tool is much better than what we had before, but the landscape has become so fractured that as a whole it's a complete shitshow.
Therefore, I think it’s because so many Rust programmers were C++ programmers they would like to move another major stronghold over.
Pure speculation though.
Happily, I haven't yet been afflicted by a strong urge to build python packaging tools and inshallah I will escape this dreadful fate.
uv manages python binaries, user python tools, venvs, project/script dependencies, lock files. Other tools do less or different e.g., pipenv may use pyenv to install the desired python version.
I've used all of these tools successfully (at different times and/or for different use cases).
uv is the best attempt to circumvent "no size fits all" so far.
If you think a language that has just one tool is better, then it just means your use-cases are very narrow.
I don't know any other language that have such variety of users, applications (besides C). There may be more popular languages but nothing with such range.
Counterpoint from “The Zen of Python”:
> There should be one-- and preferably only one --obvious way to do it.
This is a bad joke. It's a mature language where the answer to: "I want to manage my programming language version and installed libraries" is that you have to try a dozen different tools, each of which will cover some but not all of your requirements to do this one simple thing.
> I've used all of these tools successfully (at different times and/or for different use cases).
And you see nothing wrong with that? Pretty much every modern language has one way (or at most just a small handful of ways) to build a library and manage your dependencies/environment. The reason is that packaging and environment management is a side show. A necessary evil we have to do so that the actual crux of our work can be done. When I set out on a project, I don't say: "I want to spend a week figuring out which is the current environment management tool supported by the python mindshare". I don't want to deal with a dozen different ways of installing the dependencies of a package. This is insane. When I pick up a language, I want to know what is the way of managing dependencies and packaging up my stuff. And I don't want this to change on a yearly basis, doubly so for a mature language.
> If you think a language that has just one tool is better, then it just means your use-cases are very narrow.
Yes, I prefer that there's a choice of tools for say time series analysis or running a web service. Competition in those areas is good. That's how innovation is driven forward.
When it comes to package and environment management, I don't want innovation, I want stability. I want one agreed way to do it so that I don't need to fuck around with things which are completely orthogonal to the work I actually want to do and that will put bread on the table. I don't want to spend brain cycles keeping up to date with yet another hare brained way of defining what is a python package.
In my view, the reason why we are in this quagmire is because the roots of python are in a fairly simple scripting language, and the packaging has not well escaped these roots. You can have loose python files, you can have directories containing python files which are automagically modules, then we had to hack in a way to package collections of modules and manage their different versions. It's all hacks upon hacks upon hacks, and it has to be backwards compatible all the way to being able to run a loose python file.
I'm not saying this is easy to solve. It's the posterchild of the "Situation: there are 15 competing standards" XKCD. The time to solve it would've been 15 years ago while Guido was still the BDFL. There are too many stakeholders now to get any sort of consensus.
Well, that heavily depends on what you want to do. Python has a number of concerns when it comes to code and package management, some of which are not present in most other languages. Here's an incomplete list, off the top of my head:
1. installation and management of installed packages
2. management of Python versions present in an environment
3. management of virtual environments (Python version + packages installed and ready to use, in an isolated context)
4. building of distribution packages (nowadays pretty much only wheels, with or without native extensions, which depend on the target platform)
5. publishing of distribution packages (to PyPI or a compatible repo)
6. defining repeatable deployment environments (a subset of #1)
Most developers face some combination of above problems, and various tools offer solutions for certain combinations -- with a few covering all of them, to different levels of quality. It is crucial to understand your needs and select the tool(s) that offer the right solutions in the way that fits your usual workflow the best.
This article [0] is a good starting point to understanding the current Python packaging landscape, with a clear overview of which problem is covered by which tool.
My objections are to the fact that someone had to build this atrocity of a Venn diagram just to illustrate the python ecosystem: https://alpopkes.com/posts/python/figures/venn_diagram_updat...
And in this very thread, people seem to accept that this is fine. There's nothing wrong with the fact that there are 6 separate tools just for building a package, some support publishing, some don't, some also manage environments or python versions? Which of these are currently supported, which are deprecated, which are going to become deprecated in 2025?
But also there's a tool which only does publishing (twine)? The diagram is not even correct, because conda itself requires package building, except it's about building conda packages, which are cross-platform/language and separate from building a python package.
Why is there a separate set of tools for package management and package publishing?
The blog post is indeed helpful to allow someone new to python to at least see what options there are and roll the dice, but it will also raise extremely serious alarm bells that there's something fundamentally rotten at the core of the python ecosystem.
The fact that I need to read some unofficial post from 2023 to gain an overview of the python packaging and environment management ecosystem is itself completely nuts. And I can guarantee you that by now this blog post is getting outdated, because some mad genius is cooking the new best tool and ready to unleash it on the unsuspecting world.
The only case where this question is rhetorical is when you do not really use Python enough to require deciding which management tool to use. Which tells me everything I need to know about you.
But yes, let's go throwing around thinly veiled insults instead. This tells me everything I need to know about you :)
pip solved a lot of baseline problems. It doesn't solve all of them. There were a bunch of failed attempts to be "better pip". They have not worked, really, but people stick around to some tools despite this.
I do think uv is different, on account of working and being very reactive to ecosystem pains.
(direnv is not Python-specific! It's just a tool to set env vars in a directory. But because Python venv's can work through setting two env vars....)