For those of you who install your virtual environments into a global directory (e.g. virtualenvwrapper users, `$WORKON_HOME`), what's the primary reason you do that instead locally into your workspace (e.g. `.venv` directory next to your code)?
Easy to delete all environments
7.4%
Environment sharing/reuse
24.2%
No reason/habit/tool default
52.6%
Other (w/ follow-up comment to explain)
15.8%
Poll ended at .

@brettcannon I tend to avoid putting venv in-project since I started doing some work on windows; sometimes I’m in WSL, sometimes I’m in windows native. Keeping the venv globally avoids conflicts.

I also find myself using multiple python versions for one project lately, so I often use pyenv’s virtualenv wrapper, which stores venvs globally and lets you refer to it with an in project .python-version file

@LucidDan Does a project associate with a single environment (can be one per Python version)? I.e. how could a tool know what environment you wanted to use with your project?

@brettcannon with pyenv, the .python-version file points to the venv name (which is a directory somewhere in $HOME/.pyenv). Pyenv auto activated the right venv when you cd into the project where the python-version file is.

If I want to switch to another venv with another python ver I just “pyenv use <venv name>” which temporarily activates that instead. This works for me as I usually just want to use other versions a briefly to test things

@brettcannon if I’m not using pyenv, I’m generally relying on Pycharm to keep track for me. And then I have to switch interpreter in the project settings to change versions. I still tend to use a global dir for those envs though, partly out of habit I guess…
@LucidDan So either you're using a tool default for pyenv or you just have to do it manually.
@brettcannon yes. I would make the distinction (based on the poll wording) that I use the tool default because it suits my purposes rather than just because it’s the tool default. Hence the vote for “other”.