@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
@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