Look for the activation script on the venv folder

[luispabon]

I'm not sure if venv used to be in the bin folder, but the current convention is to place it in projectdir/venv. This updates the script to look for the activation script to source in there.

[timothybrown]

Hey, sorry it took so long to get back to you, I completely missed this pull request! (GitHub buried it at the bottom of my list!)

What version of Python are you running? On all my machines (Python 3.5.3 on one, 3.7.4 on the rest) there is no venv directory. This is with the standard python -m venv command under 3.7.4:

 $ ~  python -m venv test
 $ ~ tree -L 2 test/
test/
├── bin
│   ├── activate
│   ├── activate.csh
│   ├── activate.fish
│   ├── easy_install
│   ├── easy_install-3.7
│   ├── pip
│   ├── pip3
│   ├── pip3.7
│   ├── python -> /usr/bin/python
│   └── python3 -> python
├── include
├── lib
│   └── python3.7
└── pyvenv.cfg

4 directories, 11 files

[luispabon]

Ah, that's the difference. You're putting your venv in test/. Most projects i've worked at people tend to put it at venv/. The folder path is a mandatory arg:

~ python3 -m venv    
usage: venv [-h] [--system-site-packages] [--symlinks | --copies] [--clear]
            [--upgrade] [--without-pip] [--prompt PROMPT]
            ENV_DIR [ENV_DIR ...]
venv: error: the following arguments are required: ENV_DIR

This is on python 3.7 but afaik it's always been like that.

[luispabon]

It's probably worth thinking about finding a folder containing pyvenv.cfg then use that instead of hardcoding it to anything. I'll have a think on how to do that.

[timothybrown]

Right, as an example case I would do python -m venv project_dir, with ../project_dir being the folder path. Most of the projects I’ve worked on (Home Assistant being a prominent example) tend to use the virtual environment folder (../project_dir in my example) itself as the project directory, instead of creating a separate ../project_dir/venv directory inside the project directory. Which is what you’re saying, right? I have seen that (plus .env, .venv and env) used in the past, but just assumed it was connected to Python 2.

I agree that looking for pyvenv.cfg would be a good way to do it. Perhaps we could add an option to look in each sub-directory of the current directory for it? (Basically only look one level deep, aka non-recursive sub-directory searching.)

Another option would be to add a command called autovenv-force that would write a dotfile to the current directory. AutoVenv would look for this file (along with looking for ../bin/activate.fish as it currently does), read it, and then activate the environment it points to.

So, if you’re in ../project_dir and your venv is in ../project_dir/venv, you could use autovenv-force ./venv, which would create the file ../project_dir/.autovenv, the contents of which would simply be the path to the venv that should be activated. I know this is an extra step, but it could be useful in other cases as well (perhaps you want to share a venv between two projects).

[dgrant]

I've never seen this case where you create a virtual env and then put the project inside the virtualenv. Then it makes it very cumbersome to delete the virtualenv. You'd have to delete bin, include, lib, lib64, man, pyenv.cfg.

This PR doesn't quite solve it for me though, as I put my virtualenv in .venv (because virtual envs should be hidden, amirite?)

[dgrant]

I've provided a more robust solution in PR #2

Basically implemented what @timothybrown suggested:

Perhaps we could add an option to look in each sub-directory of the current directory for it? (Basically only look one level deep, aka non-recursive sub-directory searching.)

It should work for all 3 of our cases @luispabon @timothybrown

I use ./.venv
@luispabon uses ./venv
@timothybrown uses ./

[luispabon]

Superseded by #2

[dgrant]

@timothybrown sorry one more thing, and then I'll stop. I looked at Home Assitant and that use case is different. In that case, they are creating a virtualenv and installing a pip package (homeassistant). I don't see them actually putting any source inside the virtualenv as well. BUT, if the user was to put some files in there for some purpose, their advice is bad advice.

For example, their instructions to do this:

python3 -m venv homeassistant

could instead be:

mkdir homeassistant
python3 -m venv homeassistant/.venv

now you can potentially put some other "homeassistant" related stuff in the homeassistant folder, and later blow away the .venv folder at any time.

In some other instructions they do this:

sudo mkdir homeassistant
cd /srv/homeassistant
python3 -m venv .
source bin/activate

but that could easily just be:

sudo mkdir homeassistant
cd /srv/homeassistant
python3 -m venv .venv
source .venv/bin/activate

There's not much difference.. but in the case where we create the env in a .venv folder, it makes it easy to a) put some other files in the homeassistant directory if necessary and b) blow away the .venv folder any time without disrupting the homeassistant folder. Some potential upside and no downside.