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