alt Hacker NewsThat’s especially ironic given that inside Python part of the philosophy is “There should be one-- and preferably only one --obvious way to do it.” So why does Python’s external environment seem more like something that escape from a Perl zoo?
Replies
The one obvious way is the underlying virtualenv abstraction. Everything else just makes that part easier or more transparent.
What kstrauser said.
But with much more detail: it seems complicated because
* People refuse to learn basic concepts that are readily explained by many sources; e.g. https://chriswarrick.com/blog/2018/09/04/python-virtual-envi... [0].
* People cling to memories of long-obsolete issues. When people point to XKCD 1987 they overlook that Python 2.x has been EOL for almost six years (and 3.6 for over four, but whatever)[1]; only Mac users have to worry about "homebrew" (which I understand was directly interfering with stuff back in the day) or "framework builds" of Python; easy_install is similarly a long-deprecated dinosaur that you also would never need once you have pip set up; and fewer and fewer people actually need Anaconda for anything[2][3].
* There is never just one way to do it, depending on your understanding of "do". Everyone will always imagine that the underlying functionality can be wrapped in a more user-friendly way, and they will have multiple incompatible ideas about what is the most user-friendly.
But there is one obvious "way to do it", which is to set up the virtual environment and then launch the virtual environment's Python executable. Literally everything else is window dressing on top of that. The only thing that "activating" the environment does is configure environment variables so that `python` means the virtual environment's Python executable. All your various alternative tools are just presenting different ways to ensure that you run the correct Python (under the assumption that you don't want to remember a path to it, I guess) and to bundle up the virtual environment creation with some other development task.
The Python community did explicitly provide for multiple people to provide such wrappers. This was not by providing the "15th competing standard". It was by providing the standard (really a set of standards designed to work together: the virtual environment support in the standard library, the PEPs describing `pyproject.toml`, and so on), which replaced a Wild West (where Setuptools was the sheriff and pip its deputy).
[0]: By the way, this is by someone who doesn't like virtual environments and was one of the biggest backers of PEP 582.
[1]: Of course, this is not Randall Munroe's fault. The comic dates to 2018, right in the middle of the period where the community was trying to sort things out and figure out how to not require the often problematic `setup.py` configuration for every project including pure-Python ones.
[2]: The SciPy stack has been installable from wheels for almost everyone for quite some time and they were even able to get 3.12 wheels out promptly despite being hamstrung by the standard library `distutils` removal.
[3]: Those who do need it, meanwhile, can generally live within that environment entirely.
Because a lot of people have no clue about packaging or how to write compatible software, one that is actually installable as normal application. I suspect a lot of them learned stuff in node.js or ruby ecosystem first and this is the result. Same as requiring using docker to install or build an application. It isn't cool, funny or right way to do stuff. I still don't get what was so wrong about venv that anyone needed uv. I have no need to even try and i'm writing python stuff so long that i cannot even estimate it. To me it feels like reinvention for sake of rewrite in rust. If it is so good, ok, i get it, it might be - and all that good stuff needs to go back to python as python.