Handling virtualenvwrapper error messages

[rsyring]

I'm considering moving to vex and have lots of virtualenvs that were created with virtualenvwrapper. When activating these virtualenvs, I get:

/home/rsyring/.virtualenvs/hllapi/bin/python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks. 

If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenv has been installed for
VIRTUALENVWRAPPER_PYTHON=/home/rsyring/.virtualenvs/hllapi/bin/python and that PATH is
set properly.

I guess this is because virtualenvwrapper.py is installed in the global python and vex is switching to the hllapi python before the virtualenvwrapper script is ran. What would be the best way to handle this? Anything vex can do?

[sashahart]

Ugh, thanks for the report. I don't have bandwidth at this very moment but I'll take a closer look this weekend.

[sashahart]

Maybe the best way to handle this, for you, in the short term, would be to recreate the virtualenvs you are going to use in the near future; they are supposed to be disposable (this is why people do things like 'pip freeze > requirements.txt' and why they can't really be relocated, etc.) I make this recommendation not because this is your fault or because I don't want to do anything, but just because it'll get you a complete solution quite soon. I suspect that activating such a clean virtualenv with 'workon' will not actually write the virtualenvwrapper files which cause this message, so I suspect that the above workaround will permit you to continue using virtualenvwrapper if you like.

Making it so that other people don't ever have to think about this might be a longer term project than one day. At least I have to inspect exactly what hook_loader is doing and try some ideas.

Let's talk about what a good solution might look like.

I don't suppose I can actually allow virtualenvwrapper hooks to run without copying the virtualenvwrapper feature of running magic shell hooks, which I don't want to do. It's more coupling to the shell and few people use that feature. Another possibility I don't want is to install virtualenvwrapper in every new virtualenv. I think the people who do use virtualenvwrapper hooks are probably still best served with virtualenvwrapper, vex has no reason to exist if it becomes too crufty. So I am not entertaining solutions where the hooks actually run.

At the other extreme, it would be ugly to have vex munging/rewriting/deleting files from virtualenvs created by virtualenvwrapper, just in order to get rid of the error. Also, I want to have a "live and let live" attitude toward parallel installs of both tools. Also, users of hooks might have put information in them that is important to them in which case I don't want to automatically destroy that data.

So I don't want to run the hooks, but I do want to leave them in-place, which leaves two problems. One is that some users may expect hooks to run, since I'm not going to do that this has to be solved with documentation or at most a single warning message. The other problem is all these ugly messages you've mentioned, which probably don't really hurt anything but might confuse somebody.

If possible, I think it would be nice to somehow just suppress the message and just go ahead and use the virtualenvs WITHOUT running virtualenvwrapper hooks. What do you think about that idea?

[rsyring]

Thanks for the detailed reply. Once I realized that the problem came from sourcing virtualenvwrapper.sh in my .bashrc, a solution popped out for me:

virtualenvs

export WORKON_HOME=$HOME/.virtualenvs
if [ -z "$VIRTUAL_ENV" ]; then
# activate virtualenvwrapper if VIRTUAL_ENV is not set. Avoids warnings when using vex.
source /usr/local/bin/virtualenvwrapper.sh
fi
Since vex has already set VIRTUAL_ENV, I can use that to indicate to bash that I don't want to load virtualenvwrapper. Maybe just add this to the docs?

[sashahart]

Thanks! I am going to investigate if there is a more seamless way to manage this on behalf of users, but if there is nothing particularly clean to do then I will add your suggestion to the README. In the interim I will keep this issue open as a reminder.

[sashahart]

Hey, look what I saw when I installed virtualenvwrapper with pip install --user

/usr/bin/python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks. 

If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenvwrapper has been installed for
VIRTUALENVWRAPPER_PYTHON=/usr/bin/python and that PATH is
set properly.

Then I installed it with "sudo apt-get install virtualenvwrapper" (ugh, no!! but for testing...)
I used mkvirtualenv to make some virtualenvs with virtualenvwrapper.
they worked perfectly with vex or with workon. oh snap.

Bad news: I can't help you
Good news: this is purely virtualenvwrapper having a problem

Tell me if I'm wrong and I'll reopen this.

[sashahart]

Somehow I wasn't replicating this on my normal home setup, which was sort of interesting, I have kept holding out hope that I was going to get around to looking into this properly and maybe finding some cheap way of fixing this without user intervention.

But anyway I decided I was being lazy and just replicated this in a clean container and read through virtualenvwrapper's shell script.

I guess the thing to do with this is to document in README that this message is a harmless consequence of sourcing virtualenvwrapper.sh, and suggest your solution as a way of getting rid of the message without just getting rid of virtualenvwrapper. Overall this seems cleanest and most polite.

Alternatively, I could probably sabotage virtualenvwrapper's startup by supplying a stupid value for VIRTUALENVWRAPPER_PYTHON or even providing a fake virtualenvwrapper.hook_loader inside the virtualenv vex 'activates'. This would provide a cleaner user experience (less setup bullshit and spam to think about) at the cost of doing something grubby.

[sashahart]

Actually I'm rather fond of VIRTUALENVWRAPPER_PYTHON=:

It works fine for me and doesn't make the tests yell (whatever that means)

Thus