Support for postactivate

[stereoit]

Hi,
I've started to use your virtualfish and I like it. Would it be possible to add support for postactivate actions? With virtualenvwrapper I can put this into bin/postactivate:

!/bin/bash

This hook is run after this virtualenv is activated.

PROJECT_PATH=/path/to/project
export DJANGO_SETTINGS_MODULE=project.settings
export PYTHONPATH=$PROJECT_PATH/src
cd $PROJECT_PATH

Also, aliases from acvirtualenv to workon might be handy.

[daisylb]

Thanks for using virtualfish :) Aliases have been added.

As to postactivate scripts, I feel the most...

what's the Fish version of pythonic? Fishy?

...the most fishy way to do it might be using events instead of sourcing files (although input on this is appreciated). That said, I don't know how versatile they are, so I'll leave your pull request open for now too.

[daisylb]

Okay, tell me what you think of that. Personally, I prefer events to hook scripts for global stuff, but I'm in two minds about using them for per-env stuff.

[stereoit]

Hi,

personally, I just needed to have it done and I am by no means a python
or fish script expert.

I agree the hooks might be the best way, but until that time the simple
test for .fish file and activation works for me.

I've am trying to switch to fish since yesteday, I am using version
2.0.0 from http://ridiculousfish.com.

robert

On 07/26/2012 01:50 PM, Adam Brenecki wrote:

Okay, tell me what you think of that. Personally, I prefer events to hook scripts for global stuff, but I'm in two minds about using them for per-env stuff.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

stereoIT - Open Source Technology Partners
http://www.stereoit.com
mobile: +420 776 762378

[daisylb]

I'm only a Fish beginner too :)

Well, events are all implemented now, so you can write a function like this:

function whatever --on-event virtualenv_did_activate:mysite
    set PROJECT_PATH /path/to/project
    set -e DJANGO_SETTINGS_MODULE project.settings
    set -e PYTHONPATH $PROJECT_PATH/src $PYTHONPATH
    cd $PROJECT_PATH
end

Then, once it works, save it with funcsave.

That said, I'm still not sure if this is the best approach.

[stereoit]

Hi Adam,

for the first moment it looks like an overkill, but if you document one
usage (one the project page) that would be the best.

I mean: OK I need virtualenvwrapper in fish, I check google and find
your page. The documentation should give perfect sense for newcommers
(how to install, add postactivate stuff).

So at the moment I am not sure where this is supposed go, shall I just
added that function to the rest of
.config/fish/extensions/virtual.fish ? I am starting to understand, I
can have my postactivate stuff with me all the time (compared to
manually adding the postactivate script to every instance of a project),
that is great.

Also as many might come from virtualenvwrapper, would it be possible to
have aliases for common things?

If you manage to resolve those little things, that would be a perfect
tool to use.

Many, many thanks for current work indeed.

robert

On 07/26/2012 02:30 PM, Adam Brenecki wrote:

I'm only a Fish beginner too :)

Well, events are all implemented now, so you can write a function like this:

function whatever --on-event virtualenv_did_activate:mysite
    set PROJECT_PATH /path/to/project
    set -e DJANGO_SETTINGS_MODULE project.settings
    set -e PYTHONPATH $PROJECT_PATH/src $PYTHONPATH
    cd $PROJECT_PATH
end

Then, once it works, save it with funcsave.

That said, I'm still not sure if this is the best approach.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

stereoIT - Open Source Technology Partners
http://www.stereoit.com
mobile: +420 776 762378

[stereoit]

Adam,

I've today tested your updates and they works very well. I just added
also the completion for the workon and the script from below to the
bottom of virtual.fish (had to change set -e -> set -gx). Now all works
perfectly!

Thank you,

Robert

On 07/26/2012 02:30 PM, Adam Brenecki wrote:

I'm only a Fish beginner too :)

Well, events are all implemented now, so you can write a function like this:

function whatever --on-event virtualenv_did_activate:mysite
    set PROJECT_PATH /path/to/project
    set -e DJANGO_SETTINGS_MODULE project.settings
    set -e PYTHONPATH $PROJECT_PATH/src $PYTHONPATH
    cd $PROJECT_PATH
end

Then, once it works, save it with funcsave.

That said, I'm still not sure if this is the best approach.

---

Reply to this email directly or view it on GitHub:
#1 (comment)

stereoIT - Open Source Technology Partners
http://www.stereoit.com
mobile: +420 776 762378

[daisylb]

I actually added the aliases you asked for in d793c95 on Thursday (you need to set VIRTUALFISH_COMPAT_ALIASES before sourcing virtual.fish), but I have documented it a bit better now. Also added better docs for the events (and added a few more events).

Completion for workon and deactivate should work without adding anything now (If it doesn't, let me know).

[mrcoles]

Sorry, years later, but was there a resolution for postactivate or is it to make the --on-event function, also using set -gx?

If so, is there a preferred location for such function? Currently, I would put such a thing in ~/.config/fish/config.fish, but seems more decoupled and easier to cleanup for me if it were somewhere inside the directory where the virtualenv content lives, e.g., in ~/.viratuelenvs/NAME_OF_MY_ENV/.

[stereoit]

Hi, this is what I settled on:

All virtual envs in one file : ~/.config/fish/extensions/virtual.fish

function nadacnik.cz --on-event virtualenv_did_activate:<some-project>
    set PROJECT_PATH /path/to/some/project
    set -gx DJANGO_SETTINGS_MODULE some-project.settings
    set -gx PYTHONPATH $PROJECT_PATH/src $PYTHONPATH
    cd $PROJECT_PATH
end

And this thing is used by .config/fish/workon_funcs.fish (which I got
soemhwere from internet)

function fish_prompt
    if [ -z $VIRTUAL_ENV ]
      printf '%s@%s%s[%s]%s$ ' (whoami) (hostname|cut -d . -f 1) (set_color
$fish_color_cwd) (pwd) (set_c>
    else
      printf '%s(%s)%s %s@%s%s[%s]%s$ ' (set_color -b blue white) (basename
"$VIRTUAL_ENV") (set_color no>
    end
end

function workon -d "Activate virtual environment in $WORKON_HOME"
  set tgt {$WORKON_HOME}$argv[1]
  if [ -d $tgt ]
    cd $tgt

    deactivate

    set -gx VIRTUAL_ENV "$tgt"
    set -gx _OLD_VIRTUAL_PATH $PATH
    set -gx PATH "$VIRTUAL_ENV/bin" $PATH

    # unset PYTHONHOME if set
    if set -q PYTHONHOME
       set -gx _OLD_VIRTUAL_PYTHONHOME $PYTHONHOME
       set -e PYTHONHOME
    end
  else
    echo "$tgt not found"
  end
end

complete -c workon -a "(cd $WORKON_HOME; ls -d *)"

function deactivate -d "Exit virtualenv and return to normal shell
environment"
    # reset old environment variables
    if test -n "$_OLD_VIRTUAL_PATH"
        set -gx PATH $_OLD_VIRTUAL_PATH
        set -e _OLD_VIRTUAL_PATH
    end
    if test -n "$_OLD_VIRTUAL_PYTHONHOME"
        set -gx PYTHONHOME $_OLD_VIRTUAL_PYTHONHOME
        set -e _OLD_VIRTUAL_PYTHONHOME
    end
    set -e VIRTUAL_ENV
end

Hope it helps

Robert

On Sun, Jul 17, 2016 at 8:13 PM, Peter Coles notifications@github.com
wrote:

Sorry, years later, but was there a resolution for postactivate or is it
to make the --on-event function, also using set -gx?

If so, is there a preferred location for such function? Currently, I would
put such a thing in ~/.config/fish/config.fish, but seems more decoupled
and easier to cleanup for me if it were somewhere inside the directory
where the virtualenv content lives, e.g., in
~/.viratuelenvs/NAME_OF_MY_ENV/.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEDnAF6bmyVFM9RNgZ25bbLj_hXVcEaks5qWnCvgaJpZM4AFYQO
.

stereoIT s.r.o.
Heřmanova 23
107 00 Praha 7
mob: +420 776 76 23 78

[justinmayer]

For what it's worth, I handle this use case via the Virtualhooks module for Tacklebox / Tackle.

[daisylb]

To directly answer @mrcoles' question: yes, the addition of Fish events was the resolution of this issue, and support for hook scripts will not be added to virtualfish core.

As I've already mentioned in #8 and #31, I'm not opposed to merging a plugin that adds support for hook scripts; it could easily be as simple as the link @justinmayer posted.

If all you're using the hooks for is to set and unset environment variables, there's also #92, which will add support for that directly once it's implemented.