Closed sgtsquiggs closed 2 years ago
Hey Matthew. Could you elaborate regarding precisely what you are trying to accomplish? It's not clear from the brief description provided.
Activating a virtual environment, regardless of which tool does it, entails setting the shell's $PATH
such that the environment's executables take precedence. VirtualFish is no different in that respect, and the operation performed is quite straightforward.
In other shells we just source path/to/venv/activate but this obviously doesn't work with fish
Well, in the virtual environments I have seen, a Fish-specific activation script is already included at your-virtual-environment/bin/activate.fish
, so other than appending .fish
to your usual invocation, I don't see any other differences in terms of process flow.
In any case, could VirtualFish source that file instead of using its own activation logic? Sure, but in the absence of presented evidence to the contrary, I don't believe that would accomplish anything, and the reasons why it doesn't activate via Virtualenv's activate.fish
are already explained in the FAQ.
You're right 🤦
Thanks!
Hi there. I found this issue while searching for duplicates and I think it asks for what I think I need. So, having virtualfish keep all virtualenvs in a single location is great. But it sometimes happens that I want to activate a virtualenv that's not there (because it's created by make or other tool). I've found that passing a relative path to vf activate
accomplishes the goal. It's slightly inconvenient, but it occurred to me that we can add another command to virtualfish:
function __vf_local
set -l relative_path (realpath --relative-to $VIRTUALFISH_HOME $PWD)
vf activate $relative_path/$argv[1]
end
This accepts a single argument, the path to the virtualenv, so example invocation is
vf local some-service/.venv
I've already added that function to my config, but if you think it's useful it could be added to the tool itself.
BTW, thanks for virtualfish, happy user since many years.
Many thanks for the kind words, Marcin. I'm not sure that is markedly different than source some-service/.venv/bin/activate.fish
, but I can see how your version involves less typing and probably feels more elegant.
If this were to be implemented in VirtualFish, I think perhaps it'd be better to modify __vf_activate
to support file path arguments, perhaps by detecting whether there is a slash in the argument, and if so, treating it as a file path instead of a virtual environment name within VIRTUALFISH_HOME
.
Feature Request
Currently we have virtualenvs in custom locations managed by our custom CLI tools. In other shells we just
source path/to/venv/activate
but this obviously doesn't work with fish. Can virtualfish support this activation style?