Prezto: Consider adding homebrew's python bin dir to PATH

[belak]

Description

Homebrew no longer installs python to /usr/local/bin/python which can cause virtualenvwrapper to fail with something that looks like the following:

~ % workon .../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.

~ % workon ansible
/usr/bin/python: No module named virtualenvwrapper
/usr/bin/python: No module named virtualenvwrapper

Expected behavior

virtualenvwrapper should work properly out of the box.

Actual behavior

If the user installed virtualenvwrapper using homebrew python, there is a large chance it will not work.

Steps to Reproduce

1. Install python with homebrew
2. pip2 install virtualenvwrapper
3. Restart the shell
4. workon # This fails with the first error
5. workon "" # This fails with the second error

Potential Fix

This can be fixed by adding /usr/local/opt/python/libexec/bin to the path, though I'm not sure if we should or not as it shadows the system python.

Versions

• Prezto commit: 3f556400e70a8003a484836b5c5d4a384468d1ca
• ZSH version: 5.3.1
• OS information: macOS Siera 10.12.6

[diraol]

@belak , me and @indrajitr were just discussion changes related to virtualenvwrapper on python module (https://github.com/sorin-ionescu/prezto/issues/1413). Maybe this can be fixed all togheter.
Maybe one possible solution is to add this path to the following array:

https://github.com/indrajitr/prezto/blob/a5e751a2614fe6b43e162785d278ede07377cba3/modules/python/init.zsh#L107

Would it work?

[indrajitr]

Well, the motivation behind #1396 and #1403 was primarily driven by this and then I took the opportunity to clean things up further :)

As per updated usage doc, setting VIRTUALENVWRAPPER_PYTHON (and possibly VIRTUALENVWRAPPER_VIRTUALENV) should help.

For homebrew-ed python, it would be:

export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python2
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/local/bin/virtualenv

This might be less intrusive instead of shadowing system defaults for python. It also allows switching between python2 and python3 lazily.

What say?

[belak]

I didn't know those variables were there... and I'll definitely use them as a temporary fix... but it would still be nice for this to work out of the box with homebrewed python.

[jeffwidman]

Most folks' typical workflow was pip install virtualenvwrapper into the system site packages and it just worked.

Homebrew broke this workflow by 1) no longer shadowing system python, and 2) no longer shipping symlinking pip to pip2.

Most users will realize when they can't find pip that they need to use pip3/pip2, but that will create a problem because virtualenvwrapper is now installed for python3/python2, but not for python. So when virtualenvwrapper runs and calls python, it won't find virtualenvwrapper/virtualenv python packages in the system python's site packages.

For solutions, I actually think that explicitly setting VIRTUALENVWRAPPER_PYTHON is the cleanest fix, not a hack, because I prefer we fix this in a way that does not shadow the system python. Here's how I did it in my dotfiles: https://github.com/jeffwidman/dotfiles/commit/74c8a522c564991c12da1b45d08f4fd285d763f4

The problem for prezto is we don't know if the user installed virtualenvwrapper using pip3 or pip2, so we don't know whether to point it at python3 or python2.

I can't see a clean way to handle this other than checking both pip3 followed by pip2 for the presence of virtualenvwrapper and if found then export the variable, but that feels brittle.

If we do any overriding, I prefer that we default to python3/pip3 and allow folks to override back to python2/pip2 if they want.