Brett CannonDec 20, 2022
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 .
Show threadChip WardenDec 20, 2022
@brettcannon With `.venv` in the project directory, someone will sometime, somehow, no matter how many precautions are taken, check the virtual environment into version control. I have seen this happen multiple times at multiple employers.
Show threadBrett Cannon

@lgw4 We have seen this for the Python extension for VS Code. This is why we drop a `.gitignore` file containing just `*` when the extension creates a virtual environment via its `Create Environment` command.

Does the tool you use tie the environment back to the project directory somehow? The motivator for me asking this is how does one know what environment to use for a project directory?

Dec 20, 2022 at 7:47pmWeb
Show threadChip WardenDec 20, 2022

@brettcannon For personal use, I switch between `virtualenvwrapper` and `virtualfish`. My team at work selected Poetry, but configured to use `~/.virtualenvs` for virtual environments.

I guess that is a long way of saying "yes."

Show thread64kbJan 7, 2023
@brettcannon @lgw4 virtualenvwrapper has a way of associating it.
In zsh I often use an extension to automatically set it on cd... It only bites me in the times when I use a secondary environment for the same source directory and navigate in and out of it
Show thread64kbJan 7, 2023
I guess I do the reverse with virtualenvwrapper, workon will send me to the project dir.
I think there is a file like .project that gets put in the virtualenv.