Closed cecep2 closed 3 years ago
One detail to add: This is still an imperfect solution. If I connect my project in $PROJECT_HOME
to a virtualenv using an activation file, the virtualenv of this project might not be auto-deactivated IF I activated it with vf workon project
. This is because:
a) switching into project directories with vf workon project
doesn't set the VF_AUTO_ACTIVATED
flag, that only happens when the cd
command is used
b) the virtualenv specified in the activation file might not have a corresponding directory in $PROJECT_HOME
and with this patch we only auto-deactivate if $VIRTUAL_ENV
is in vf lsprojects
I think a more complete solution would require changes to the projects plugin where we could set something like a PROJECT_ACTIVATED
flag that would be checked in the auto-activation plugin, but I remember that a similar proposal was rejected earlier because it's problematic from a "principle of least astonishment" perspective. However, for me personally the solution here is 'good enough' since I don't use activation files for projects stored in $PROJECT_HOME
.
@cecep2: Many thanks for the fix. I don't recall the previous discussion, but I'm not opposed to us divining a more elegant solution at some point down the road.
Uff, I just realized that #209 introduced a rather unfortunate bug: when I just want to activate a venv that is not connected to any project or has an activation file (
vf activate testvenv
), #209 will immediately deactivate the venv when changing the directory (because it's not in$PROJECT_HOME
). To fix this, I now also check if $VIRTUAL_ENV is invf lsprojects