Make the auto activation and projects plugin play nice together

[cecep2]

The goal of this PR is to ensure that projects activated with vf workon are deactivated again when leaving the project's directory in cases where both the projects and the auto-activation plugins are used.

• Activating a venv and switching directory using vf workon now sets VF_AUTO_ACTIVATED flag if auto activation plugin is sourced
• In the auto activation plugin, check if projects plugin is sourced. If so, check if PWD is a project directory to make sure changing into project subdirectories does not deactivate venv if no activation file is present

I'm not exactly an expert in Fish and wasn't sure what's the best way to check if another plugin has been sourced. I just check if a particular function from the projects or auto-activation plugin is available using type -q, but please advice if there is a better way to do this

[justinmayer]

I think I misunderstood your comment that inspired this PR. I did not realize that you are looking for auto-deactivation to occur even when no auto-activation occurred. From a "principle of least astonishment" perspective, I am not entirely certain that is sensible default behavior for folks who use both of these plugins.

Regarding implementation... I realize that it's hard to keep plugin functionality separate when folks want to use multiple plugins together, but these changes are a bit more involved / inter-twined than I think independent plugins should perhaps be. Moreover, the if type -q __vf_workon call to check whether the Project plugin is loaded will probably not function properly if the Auto-Activation plugin is loaded before the Projects plugin.

As far as implementation, I think perhaps one of the simplest solutions would be to add three lines to the else clause here:

virtualfish/virtualfish/projects.fish

Lines 131 to 140 in 66019c9

	function workon
	if not set -q argv[1]
	set_color blue; echo "Projects:"; set_color normal
	vf lsprojects
	set_color blue; echo -e "\nVirtual environments:"; set_color normal
	vf ls
	else
	vf workon $argv[1]
	end
	end

:

            else
                vf workon $argv[1]
                if type -q __vfsupport_auto_activate
                    set -g VF_AUTO_ACTIVATED $PWD
                end
            end                                                        

That does the trick in my testing and works no matter how plugins are loaded, albeit only for workon and not for vf workon. Achieving the latter would probably be more involved.

So... I'm not yet sure whether it's best to do this at all, and if so, in what way. I fully understand you invested time in this endeavor, and I want to respect that while simultaneously ensuring the long-term maintainability of the code. 😅 I thought I'd at least write down my initial impressions so we can discuss further.

[cecep2]

Thanks for the feedback - I'm not a programmer by training, so this is helpful :-)

I think at least in cases where there is an activation file in the project dir, auto-activation should be triggered so that the venv is auto-deactivated when leaving. Currently, when I use cd <path/to/project>, auto-activation is triggered, but when I do the same thing using workon <project> it is not. I think this would boil down to a minor addition to the projects plugin and no changes to the auto-activation plugin, and the workaround to my desire to always auto-deactivate projects is to add a .venv file to each project.

My personal preference would be to make the auto-activation plugin fully project aware without touching the projects plugin at all, would this still be too inter-twined?

[justinmayer]

My personal preference would be to make the auto-activation plugin fully project aware without touching the projects plugin at all, would this still be too inter-twined?

That sounds reasonable enough to me; I agree that this logic would best located in the auto-activation plugin. If at some point in the future some folks find this behavior change undesirable, I suppose down the road we could consider adding a preference setting.

[…] the workaround to my desire to always auto-deactivate projects is to add a .venv file to each project

That certainly is the simplest solution and doesn't seem like a significant burden to me. But I understand if you would still like to implement a solution that skips that step.

[cecep2]

Now the Projects plugin remains untouched, everything happens in the Auto activation plugin. I don't check if the Projects plugin is sourced and just check if a $VIRTUAL_ENV/.project file exists instead. I think it's reasonable to assume that users having such a file in their virtualenv use the Projects plugin, and this way it doesn't matter in which order these plugins are sourced.

[justinmayer]

While there are Projects plugin use cases that don't involve .project files, such as using vf project foo to create new project+virtualenv combinations that automatically activate and change directory upon vf workon foo, I don't think we need to add auto-deactivation to every single use case. Explicitly adding .venv / .project files as needed is a very easy way to address alternative use cases, which along with the changes in this PR should be sufficient to address nearly everyone's auto-deactivation needs.

Many thanks for your continued work on this endeavor! 💫

[cecep2]

Thanks for merging! I admit I totally forgot to take into account that creating a new project doesn't automatically add a .project file to the virtualenv. Perhaps the docs should add that a .venv or .project file is required for auto-deactivation, currently we claim that using auto-activation alongside projects would always auto-deactivate projects. But anyways, this PR already makes me happy enough, glad it got merged :-)