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 threadCarlton Gibson ๐Ÿ‡ช๐Ÿ‡บ
@brettcannon two reasons: nice to see all the venvs that are around, and I donโ€™t want the venv in the project folder (I have cdvirtualenv and cdsitepackages for the times I do actually want to rummage)
Dec 20, 2022 at 6:50pmWeb
Show threadBrett CannonDec 20, 2022
@carlton What would you think if there was a symlink from `.venv` back to the virtual environment? How about a file that listed the directory of the virtual environment?
Show threadCarlton Gibson ๐Ÿ‡ช๐Ÿ‡บDec 20, 2022
@brettcannon Iโ€™d probably find a symlink noisy, but Iโ€™d have no problem at all with a file (a dot file) saying where the venv was. (That would help tools with discovery Iโ€™d imagine)
Show threadBrett CannonDec 20, 2022
@carlton That's one of my thoughts on this; see https://fosstodon.org/@brettcannon/109547636668367144 for a discussion I'm having on this very idea.
Show threadCarlton Gibson ๐Ÿ‡ช๐Ÿ‡บDec 20, 2022

@brettcannon Hmm 404 there right now.

(It's my ๐Ÿ›Œ time so I'll check in the morning.)

Thanks.

Show threadBrett CannonDec 20, 2022
@carlton If it keeps 404'ing for you, it's a conversation with Simon that came off the poll, so it's easy to find
Show threadCarlton Gibson ๐Ÿ‡ช๐Ÿ‡บDec 21, 2022
@brettcannon i think the visibility must be set to mentioned only. No worries. Iโ€™ll imagine ๐Ÿ˜œ
Show threadBrett CannonDec 21, 2022
@carlton It's basically your suggestion: a file that points to the environment. Toyed with reusing the `.venv` name and `.venv-path`.
Show threadืฉื™ ื‘ืจื’ืจ   Shai BergerDec 20, 2022
@brettcannon @carlton
I'm putting my followup comment for "other reason" here:
WDYM *The* virtual environment?
In some of my projects, I use more than one (e.g. a long term project where I've had to work on env upgrade while the old env is still in use in production).
That need grew into a general habit, I'm used to workon. The idea of switching a virtualenv because I changed directory seems scary.
Show threadBrett CannonDec 21, 2022

@shaib @carlton There will be a follow-up poll around multiple environments per project; one thing at a time. ๐Ÿ˜‰

As for switching per directory, that's entirely how I work and I think it's great since I never have to worry about using the wrong environment for the project. I have one primary environment I directly dev in and then let nox handle testing against other versions. If I have to create a quick environment then it's cheap since the wheels are already cached from nox installing them.

Show threadืฉื™ ื‘ืจื’ืจ   Shai BergerDec 21, 2022
@brettcannon @carlton
I should maybe try that some day
Show threadCarlton Gibson ๐Ÿ‡ช๐Ÿ‡บDec 21, 2022
@shaib @brettcannon Yes, this too. I use tox (and the devenv option) a lot for this, but also have named venvs managed with virtualenvwrapper.
Show threadCarlton Gibson ๐Ÿ‡ช๐Ÿ‡บDec 20, 2022
@brettcannon also I use mktmpenv (which does what you imagine) a lot, and then it is handy for them to be in a know place (for when I forget to deactivate to clean them up)