Generate missing .project

[ratson]

vf connect is not working properly because of missing the .project file.

[justinmayer]

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.

[ratson]

@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

[justinmayer]

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.

[ratson]

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

[justinmayer]

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! 💫