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/

> 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.

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).

> 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.

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.)