And this works about 25% of the time. The rest of the time, there is some inscrutable error with the version number of a dependency in requirements.txt or something similar, which you end up Googling, only to find an open issue on a different project's Github repo.

Someone needs to make an LLM agent that just handles Python dependency hell.

"Someone needs to make an LLM agent that just handles Python dependency hell."

This is why they are constantly delaying GPT 5.

Haha fair enough—if they can solve the Python situation, I'd be fine slapping the "AGI" label on it.

As someone who doesn't develop in python but occasionally tries to run python projects, it's pretty annoying to have to look up how to use venv every time.

I finally added two scripts to my path for `python` and `pip` that automatically create and activate a virtual env at `./.venv` if there isn't one active already. It would be nice if something like that was just built into pip so there could be a single command to run like Ruby has now with Bundler.

`uv` is great for this because its super fast, works well as a globally installed tool (similar to conda), and can also download and manage multiple versions of python for you, and which version is used by which virtualenvironment.

While my uv use is still early days, i would second this recommendation. I've found it to have the functionallity i miss from conda in venv, but faster and more reliable than conda.

I am also using conda and specifically mamba which has a really quick dependency solver.

However, sometimes repos require system level packages as well. Tried to run TRELLIS recently and gave up after 2h of tinkering around to get it to work in Windows.

Also, whenever I try to run some new repo locally, creating a new virtual environment takes a ton of disk space due to CUDA and PyTorch libraries. It adds up quickly to 100s of gigs since most projects use different versions of these libraries.

</rant> Sorry for the rant, can't help myself when it's Python package management...

Same experience. They should really store these blobs centrally under a hash and link to them from the venvs

Virtual environments with venv don't answer the python version problem unless you throw another tool into the mix.

uv solves this problem.

  uv venv python3.11

done.

conda and uv do manage python versions for you which is part of their appeal, especially on systems that don't make it super straightforward to install multiple different versions of pre-compiled runtimes because their official OS channel of installing python only offers one version. At least on macos, brew supports a number of recent versions that can be installed simultaneously.

Hmm? My venvs do include the Python version (via symlink to /bin). Don't yours?

If you use something like uv (expanded here: https://news.ycombinator.com/item?id=43904078), I think it does. But if you just do `python -m venv .venv`, you get the specific version you used to create the virtual environment with. Some OSes seem to distribute binaries like `python3.8`, `python3.9` and so on so you could do `python3.8 -m venv .venv` to look one env to a specific version, but a bit of a hassle.

The GP's problem was (apparently) an inability to install the right python version, not an inability to select it.

Conda does! `conda create -n myenv python=3.9`, for example