Closed ratson closed 3 years ago
Can you describe your workflow, what commands you ran, what you expected, and what you observed instead? Otherwise it’s impossible to even begin evaluating your submission.
@justinmayer
vf install compat_aliases projects environment
mkvirtualenv testenv
setvirtualenvproject .
mkdir test
cd test
setvirtualenvproject .
cd ..
workon testenv # this won't cd to `test` dir without this fix
setvirtualenvproject
is a compatibility alias for vf connect
, which creates a .venv
file in the project directory with the name of the associated virtual environment. If fooproject
is in $PROJECT_HOME
, and you then vf workon fooproject
, the associated virtual environment will be activated, and the directory will be changed to $PROJECT_HOME/fooproject
.
.project
files work in the other direction. You run workon fooenv
, and VirtualFish finds & activates the fooenv
environment, opens the .project
file inside, and then switches to the project directory specified within.
So which strategy you use depends on your individual filesystem layout and workflow preferences. In any case, I have reservations about overloading vf connect
with creating both of those files, because I have not fully explored (nor do I have time to do so) what effects that will have in different circumstances.
As background, I recommend reading through #134 thoroughly. I added preliminary support for .project
files shortly thereafter, documenting in the Project plugin docs that for now the supported method for creating them is:
echo $PWD > $VIRTUAL_ENV/.project
Slightly more characters than setvirtualenvproject
, but at least the above command keeps the two operations distinct (creating .venv
files vs. creating .project
files), which for the moment appears preferable to sorting out the ramifications of creating them both at once.
@justinmayer Thank you for the detailed reply. I was confused setvirtualenvproject
with compat
is not honor to its original behavior, but a different one.
As it is a design decision, I will close this.
p.s. I think the doc is better to refer to $VIRTUAL_ENV
instead of $VIRTUALENV
to match env variable name.
The Virtualenvwrapper compatibility aliases are not intended to be one-for-one equivalents, but rather "training wheels" for gradually switching to the underlying VirtualFish commands. So vf connect
does indeed behave differently, but there are good reasons for this difference in behavior.
I think the doc is better to refer to $VIRTUAL_ENV instead of $VIRTUALENV to match env variable name.
That was an error, which I just fixed in a4535b9. Thank you for pointing that out! 💫
vf connect
is not working properly because of missing the.project
file.