In case of a broken virtual environment, vex can install packages into the main one

[BartGo]

Consider a "broken" virtual environment directory which is empty. This actually happended to me - the directory was locked during removal of the environment and was not dropped completely. If vex is asked to install something into such "environment" it can actually install it into the main system.

Replicated like this:

pip uninstall bottle
pip freeze | grep "bottle" # bottle is not installed in the main environment
mkdir ~/.virtualenvs/testenv
vex testenv pip install bottle # should install in testenv or throw error or not install anything...
pip freeze | grep "bottle" # but now we have it in the main environment

I know it's not a very probable situation, but... vex installs a package into the main system, which is not correct. Not sure if this is related to vex, virtualenv or something specific to my environment (checked only on Windows with Git / Bash shell).

[Sasha Hart]

Your main system permissions should not allow pip to do this anyway. Conversely, you should have permissions to your virtualenvs directories. vex has no way of patching pip to enforce this.
vex isn't installing any packages. pip is installing packages. vex is simply starting the pip process that you described verbatim on the command line. pip uses its environment variables to decide where it wants to install packages. if vex has set $VIRTUAL_ENV, it is done. vex has no other influence on pip.

Early in the project I tried to do really extensive assertions to make sure the given directory was a real virtualenv. It's really not feasible because virtualenvs have a great variety of possible forms and this is actually changing frequently because it is an implementation detail of virtualenv that they do not expect other tools to depend on. I could check whether the virtualenv directory is totally empty, but then I have another issue when someone makes a directory and touches a file in it. Really the only way to detect a valid virtualenv is to use it successfully, but it is not very nice to preflight every single command with some dummy subprocess before running the user's real process.

Broken virtualenv could mean unlimited things, down to every possibly bad file in the virtualenv.

[BartGo]

That is fine, I understand. If I am worried about such situation there may be a need for a separate tool to check if the environment is valid before installing packages inside.