Problem with vex, homebrew and $PATH

[sscherfke]

If you use homebrew on OS X, you have to add something like export PATH=/usr/local/bin:$PATH to your .bashrc to allow, e.g., a homebrewed Python to shadow the system Python.

When I run vex venv bash, the path to the venv is prepended to $PATH before the .bashrc is read, so I end up with a $PATH like this: /usr/local/bin:~/.virtualenvs/venv/bin:$PATH. But it should be: ~/.virtualenvs/venv/bin:/usr/local/bin:$PATH.

I think this is no problem in virtualenvwrapper, because I source the virtualenvwrapper.sh in my .bashrc after I prepend /usr/local/bin for homebrew to my $PATH.

[sashahart]

Thanks for your question! I'm pretty sure vex can work out if you aren't specifically attached to doing things in virtualenvwrapper's way, and even interoperably with virtualenvwrapper if that is what you want.

I believe a traditional place to set environment variables like PATH is ~/.profile (or ~/.bash_profile if that is what you are using instead of ~/.profile, or ~/.zprofile if you use zsh or whatever, I am not sure of your details, but it is the same concept in any of these cases). These are only sourced when you first start a login shell - which should allow vex to have its say on PATH.

Otherwise, the way I see the situation is that you are effectively telling bash via .bashrc that you want to interfere with PATH in this specific way, which also happens to subtly defeat vex's mechanism for controlling how executables are found in order to prefer stuff in venv/bin. None of these components can distinguish the intent of doing that, whether it is meant to be an interference or should be overridden. I can't prevent you doing anything you want to every new shell's environment in .bashrc - vex has no mechanism to constrain what the subprocess does to itself by polluting its own environment variables. And I don't think I would do that even if I could: a big part of vex's premise was not to monkey with the new subprocess, not care what it is, and not try to override what it thinks best. and I hope you can understand why I'll refuse to invent alternative executable-finding mechanisms to circumvent PATH - I am pretty sure that will badly violate least-surprise and invite nasty corner cases.

So: the only way I could "solve" this problem would be to supply even more shell to run after you munged PATH, to un-munge it so vex can work.

But what is the point when you can just avoid munging it to begin with by a minor adjustment to bash config?

Since this behavior is not inherent to bash at all. and then vex can continue not caring what the processes it runs are, being shell-agnostic instead of coupling to specific shells, and not munging the environment it runs from.

If you want to use vex then give this suggestion a try - but otherwise I'm not going to make fun of you for using virtualenvwrapper, it's just tools, you know what you're doing.

[sscherfke]

Thanks for your elaborate answer.

Adding stuff to PATH in .profile instead of .bashrc indeed solves my problem and I should have been aware of that.

However, most tools (including homebrew or pipsi) suggest that you put PATH edits into .bashrc. So maybe you could add a brief note about that into vex' documentation? Just something like “Hey, please modify your PATH in .profile and not .bashrc or you may break vex.”

[sashahart]

Yes I will do this. Thank you.

[sashahart]

see d36c3c2eed82f406b85f728d8ca8f5423feb8aa2.

If you have a project and you tell people to put your thing first, other things are less likely to interfere with it (resulting in fewer tickets); if you tell them to put it in .bashrc and source ~/.bashrc, there's less confusion about what is a login shell and when the changes take effect, also meaning fewer tickets. But of course, it is shifting support burden to other projects...

Thanks again for feedback.