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 conda default. But it’s also nice when you do a yearly spring cleaning (virtual envs with PyTorch can be multiple gigabytes these days). Sometimes I override the defaults depending on the project.
@SebRaschka I actually specifically left out conda environments and asked about virtual environments. 😁
@brettcannon but conda creates & manages virtual environments ^^. So you were wondering about pure Python tools like virtualenv/venv/pyenv/poetry in particular?
@SebRaschka I would argue conda creates conda environments, which are not the same as virtual environment (i.e. what the `venv` module creates): https://docs.conda.io/projects/conda/en/latest/user-guide/concepts/environments.html . For instance, conda environment require you activate them while virtual environments do not.
Conda environments — conda 22.11.1.post15+d63470c41 documentation

@brettcannon @SebRaschka I'm with Sebastian on this, the difference between conda envs vs venvs vs {the other tools} is thin.

I'm 95% sure you can get away without activating conda envs in most cases (if you do not have any activate scripts or extra env exports). You lose some of the self-description that you _are_ using a conda installed Python, but 🤷

I somewhat regularly do `/path/to/conda/env/bin/python blah` and have not had any issues (but now I'm a bit worried....)

@tacaswell @SebRaschka My experience with VS Code suggests skipping activation is not an option in general. For example, Python 3.10.0 was released for conda which would not load without an activated environment (couldn't load zlib I think; got fixed within a month). People also expect to be able to configure things via `conda activate`.

@brettcannon @SebRaschka 😱

I remember some early discussion about those start up scripts / envs with Aaron Meurer arguing they were a Bad Idea ™️ .

Seems he was right (and I was wrong).

@brettcannon @tacaswell I remember putting the Python executable in my SLURM script and was able to run code without having to activate like Thomas said. Regarding the definition m, I see “conda activate” as a syntax/implementation-details whereas a virtual environment is more of a broader concept for having a separate virtual space next to your main installation.

@SebRaschka @brettcannon The problem is conda packages can install on activate scripts and ENVS exports so while not strictly needed for _Python_ to work (modulo the zlib bug), if you are a tool like vscode it will break a lot of users expectations that their conda installed custom-what ever well be run!

I can totally see people shipping things like ENVS for access / configuration in a conda package that exports them on activate (because I, ah, tried to do that..my coworker talked me out of it)