virtualenv
virtualenv copied to clipboard
Feature suggestion: emit an event upon activation in activate.fish
Problem: Sometimes it's useful to be able to run a function upon activation of a virtualenv. As an example, we have many projects containing a fabfile folder with its own virtualenv, when activating that venv the shell session remains inside the fabfile directory but it would be useful to be one directory up. If the activate script emitted an event, users could hook into that event to do whatever they need.
Suggested change:
Add emit virtualenv_activated $VIRTUAL_ENV to activate.fish
I've tested this, it works and is pretty useful. Happy to put it in as a PR if there's support for the idea.
I like where this is going 😃 As much as possible though I'd like to special case fish, so would you be available to look into if the other shells support similar functionality? If so we should add a similar thing to all shells that support it.
FYI. Currently, virtualenv is having its rewrite, see #697; so you might want to put it against that, activation scripts are just been added via #1454 (but feel free to add it into current master too)
As far as I can work out, there's no equivalent in bash or zsh, though Xonsh does seem to have a similar concept: https://xon.sh/docs-ahundt-sphinx-readable-theme-pypi/api/events.html
I'm very much not a shells expert though, so I could be wrong about bash and zsh.
What about powershell? 🤔
As far as I can work out, there's no equivalent in bash or zsh,
This could be easily emulated by invoking a global function created in the shell environment.
The venv activate script could check is there is a function called (example) on_virtualenv_activate and call it after the venv is set up. Then user would put that in their bashrc files.
There should also be a matching deactivate event btw, ideally before the venv is unloaded.
What about powershell?
I've not used it myself, but help New-Event shows:
The New-Event cmdlet creates a new custom event.
You can use custom events to notify users about state changes in your program and any change that your program can detect, including hardware or system conditions, application status, disk status, network status, or the completion of a background job.
Seems no longer an issue as no one reported it in 3 years.