Xkcd: Python Environment (2018)(m.xkcd.com)
m.xkcd.com
Xkcd: Python Environment (2018)
https://m.xkcd.com/1987/
16 comments
I legitimately can't understand why people believe they have a use case for `sudo pip install`, or ever did. I've seen so much cargo-culting (thankfully, generally it's all old material) suggesting the use of sudo to fix issues with pip and it's basically always at least wrong and generally dangerous. In cases I've seen where it "worked" and a user install wouldn't, it's ultimately because the root user has different environment variables.
(Also, apt-installing multiple Python versions can already mess things up, from the reports I've seen. Building from source and installing it at a custom location that won't mess things up is easy, however.)
(Also, apt-installing multiple Python versions can already mess things up, from the reports I've seen. Building from source and installing it at a custom location that won't mess things up is easy, however.)
(2018) At the time (307 points, 181 comments) https://news.ycombinator.com/item?id=16958818
Creating and using tons of python scripts under Homebrew, I had to learn by heart:
$ python3 -m venv .venv # Create a virtual environment
$ source .venv/bin/activate # Activate the virtual environment
(.venv) pip install <whatever you need> # Install stuff within the virtual environment
...
(.venv) deactivate
$ [sudo] rm -fR .venv
$ python3 -m venv .venv # Create a virtual environment
$ source .venv/bin/activate # Activate the virtual environment
(.venv) pip install <whatever you need> # Install stuff within the virtual environment
...
(.venv) deactivate
$ [sudo] rm -fR .venv
> I had to learn by heart
Can you not write shell scripts on Darwin?
> source .venv/bin/activate # Activate the virtual environment
This is a convenience, not a necessary step. All it does is manipulate a few environment variables. You can just specify the paths to the venv's pip and Python explicitly.
(Of course, you can script around the expectation of those environment variables, if you prefer that workflow.)
Also, pip 22.3 added the ability to install cross-environment, which allows for creating virtual environments much faster `--without-pip` (see e.g. https://zahlman.github.io/posts/2025/01/07/python-packaging-...).
> [sudo] rm -fR .venv
I can't fathom a reason you'd ever need sudo for this cleanup.
Can you not write shell scripts on Darwin?
> source .venv/bin/activate # Activate the virtual environment
This is a convenience, not a necessary step. All it does is manipulate a few environment variables. You can just specify the paths to the venv's pip and Python explicitly.
(Of course, you can script around the expectation of those environment variables, if you prefer that workflow.)
Also, pip 22.3 added the ability to install cross-environment, which allows for creating virtual environments much faster `--without-pip` (see e.g. https://zahlman.github.io/posts/2025/01/07/python-packaging-...).
> [sudo] rm -fR .venv
I can't fathom a reason you'd ever need sudo for this cleanup.
Homebrew is the real annoyance here.
I think the title deserves a (2018), which I estimated by explainxkcd history https://www.explainxkcd.com/wiki/index.php?title=1987:_Pytho...
Recently, people report that uv (https://docs.astral.sh/uv/) really makes a difference in Python tooling and puts poetry and of course anaconda unnessecary.
Recently, people report that uv (https://docs.astral.sh/uv/) really makes a difference in Python tooling and puts poetry and of course anaconda unnessecary.
Uv has nothing to do with anaconda becoming unnecessary. That's something that's naturally happened ecosystem-wide, over a period of years, due to build systems improving and developers publishing a broader range of pre-built wheels. There are still gaps in the system, because the standards-defined system of metadata can't capture all of everyone's needs (see https://pypackaging-native.github.io/ for an overview).
Poetry was arguably "necessary" in 2018, but pip's dependency resolver fundamentally changed in 2020.
The "vanilla" Python packaging toolchain has been gradually improving the whole time and people haven't given it much credit for that (largely because pip is still bad, and partly because they still resent that Setuptools is no longer interested in trying to be an all-in-one solution). Uv is largely possible (rather, as good as it is) because of that work (and because of the cooperation of uv project leadership with PyPA).
Poetry was arguably "necessary" in 2018, but pip's dependency resolver fundamentally changed in 2020.
The "vanilla" Python packaging toolchain has been gradually improving the whole time and people haven't given it much credit for that (largely because pip is still bad, and partly because they still resent that Setuptools is no longer interested in trying to be an all-in-one solution). Uv is largely possible (rather, as good as it is) because of that work (and because of the cooperation of uv project leadership with PyPA).
[deleted]
I tried learning Python recently to move away from .NET. Wish I hadn't spent so much time reading about the language before actually trying to do a real world project. That environment and pip stuff is terrible. Where did they get the idea to do that? No other language I've come across has tooling that ridiculous. I switched to Go instead.
If you haven't written off Python completely, I would suggest giving it a second chance using uv [1] for managing environments and Python versions. In my opinion, uv is the best thing to happen to Python in 10 years.
[1] https://docs.astral.sh/uv/
[1] https://docs.astral.sh/uv/
Uv and uvx have been such game changers when we tried to distribute our python packages.
I don't want to manage environments unless I absolutely have to. In 25 years of development with other languages, I've never had a need. I'm sure it's great in places where management has decided that's a requirement, but I don't need it, and I certainly don't want it forced on me at the language level.
ruff is a blessing as well and soon ty will make type checking so much better (or pyrefly which also seems great)
> That environment and pip stuff is terrible. Where did they get the idea to do that? No other language I've come across has tooling that ridiculous.
What exactly do you think is "ridiculous" about it? And what exactly do you believe it involves? Talk me through something you had to do that you think you shouldn't have had to do, or something you couldn't figure out how to do that you think should have been easy to do.
What exactly do you think is "ridiculous" about it? And what exactly do you believe it involves? Talk me through something you had to do that you think you shouldn't have had to do, or something you couldn't figure out how to do that you think should have been easy to do.
If you are unexperienced, I recommend you stick with uv and set the env var: UV_MANAGED_PYTHON=true
This will make uv not consider system python, only the uv-managed python versions. No more f-ing up the system python and juggling with multiple apt-installed python versions.