What are people's preferred tools for virtual environment management these days? I specifically care about being able to have hundreds of different project folders each with their own environment

I've been using pipenv for years despite not using Pipfiles - what else should I be considering in 2024?

I want a maximum of one command (equivalent to "pipenv shell") that I have to run in a directory in order to activate the corresponding environment

I use pipenv because I like to keep my virtual environments in a separate area of disk from the project folders themselves - because I keep my project folders on Dropbox (as insurance against laptop-theft-before-git-push) and I don't want to backup the environments themselves

But I know that some tools like Rye set a "don't back this up to Dropbox" flag on the folder these days https://simonwillison.net/2024/Feb/10/rye-added-support-for-marking-virtualenvs-ignored-for-cloud-sync/

@simon direnv and layout python (actually layout pyenv since that’s what I use to manage different python versions, since different projects need different pythons). echo "layout python" > .envrc; direnv allow (from memory, so might not be exactly right) and then no commands needed to activate the virtualenv after that in the directory.

@simon ugh. I have a solution to this problem that wraps up multiple answers to this question but is tied into years of bespoke shell customization. You aren’t the first one to ask this question on my TL this month and I *really* just need to disentangle and open source it.

In the interest of motivating myself to do that though, let me do some requirements gathering: how do you think about the relationship of this venv to the venv-management tools that projects use themselves? Poetry, tox, etc?

@simon If all you want is virtualenv management then I'd recommend virtualenvwrapper https://virtualenvwrapper.readthedocs.io/en/latest/command_ref.html

It creates virtualenvs in ~/.venvs/* and you can activate it by doing `workon name_of_venv`. It has good shell tab-completion and it is separate from the project folders.

@amjith My problem with `workon` is that I *really* don't want to have to think about names for my virtual environments - I want each virtual environment to be attached to a specific directory, and I also want to reserve the right to have directories with the same names in different areas of my computer use different environments

@simon I’m pretty sure a single Dockerfile ( and/or a docker-compose if there are other pieces of software involved ) with an env file per project would meet your requirements.

`docker run` is then the command

@matthiou I often have dozens of development environments live at the same time, so I've been trying to avoid the overhead of Docker for them - even just assigning ports to everything feels like more hassle than it's worth there