Pipenv: Wrong Python inside of 'pipenv shell'

[jacebrowning]

Inside of the pipenv shell subshell, I expected python to point to .venv/bin/python, but:

$ pipenv --version
pipenv, version 3.3.2

$ pipenv shell
Launching subshell in virtual environment. Type 'exit' or 'Ctrl+D' to return.

$ which python
/Users/Browning/.pyenv/shims/python

$ which -a python
/Users/Browning/.pyenv/shims/python
/Users/Browning/.local/share/virtualenvs/virtualboombox/bin/python
/Users/Browning/.pyenv/versions/3.6.0/bin/python
/Users/Browning/.pyenv/shims/python
/usr/local/bin/python
/usr/bin/python

[kennethreitz42]

you likely don't have your shell configured properly.

[jacebrowning]

With prior versions, I saw the (myproject) $ marker appear when inside the subshell.

[kennethreitz42]

correct, this will no longer occur, as fancy shells can be configured to display virtualenv information automatically

[nateprewitt]

@jacebrowning I'm able to replicate this. Whichever python .pyenv/shims/python points to is the one I get now. This seems to be a side effect of pew.

[nateprewitt]

Alright, it looks like pyenv pushes the shim to the top of the path so the virtualenv python located at /Users/Browning/.local/share/virtualenvs/virtualboombox/bin/python isn't used. The python you want is available, but I think you'll need specify your python version for now.

[kennethreitz42]

so far, i'm really not a fan of pyenv.

[nateprewitt]

Different strokes, @kennethreitz ;) It's just a conflict of python management paradigms. pew and pyenv are competing for control here and pyenv is the one taking over the shell because (I think) it's injecting itself last. That means pipenv shell ends up in a different state than pew expects. I'll look into possible options, @jacebrowning. It's not in scope to specifically support pyenv, but perhaps we can get along a little better.

Everything else works fine for me though. pipenv run uses the virtualenv python and everything else seems to run off of that.

[kennethreitz42]

I just added $ pipenv shell --compat, which runs the old way (in compatibility mode), for people that have tricky shell configurations.

Not released yet.

[kennethreitz42]

also added support for PIPENV_SHELL_COMPAT environment variable.

[jacebrowning]

FWIW, directly activating virtual environments has always worked with pyenv. Considering that virtualenv creates symlinks to whatever Python is requested, I'm not sure why a Python version manager should have any effect:

$ pipenv --version
pipenv, version 3.3.2

$ source .venv/bin/activate
(myproject) $ which python
/Users/Browning/Programs/myproject/.venv/bin/python

[nateprewitt]

@jacebrowning yeah, this is a specific behaviour of pew. I've looked into a possible patch there, but don't have anything that works with their idea of how virtualenvs work. The PIPENV_SHELL_COMPAT env variable is the way to go with pyenv.

[kstrauser]

@kennethreitz You say earlier "you likely don't have your shell configured properly." I'm having the same problem, where the virtualenv gets added in the middle of my $PATH instead of the head. How should I have it configured differently?

[AlJohri]

@kennethreitz what do you recommend instead of pyenv for python version management that works more seemlessly with pipenv?

[kennethreitz42]

@AlJohri I use homebrew-installed python-2.7.13 and 3.6.2. That's all I need.

[auvipy]

@kennethreitz in linux desktop and servers I found pyenv as a good way

[FlorianKempenich]

This is an old question but I figured my answer might help some with the same problem.
I found a way to solve the problem.

What is happening is described here by @nateprewitt:

Different strokes, @kennethreitz ;) It's just a conflict of python management paradigms. pew and pyenv are competing for control here and pyenv is the one taking over the shell because (I think) it's injecting itself last. That means pipenv shell ends up in a different state than pew expects. I'll look into possible options, @jacebrowning. It's not in scope to specifically support pyenv, but perhaps we can get along a little better.

To solve this, the solution is simple. In your .zshrc/.bashrc, instead of initializing pyenv for every new shell, simply check if the PIPENV_ACTIVE env var is set. If it is, skip the pyenv initialisation:

if command -v pyenv 1>/dev/null 2>&1; then
    if [ -z "$PIPENV_ACTIVE" ]; then
        eval "$(pyenv init -)"
    else
        echo "Pipenv shell is activated -- skipping pyenv"
    fi
fi

With this setup, the fancy version pipenv shell --fancy works seamlessly :)

[uranusjr]

Or maybe you should move pyenv init into .bash_profile instead (I am not sure what is zsh’s equivalent). profile is for login shells, and only evaluated once; rc is for non-login shells. pipenv shell launches non-login shells.

[FlorianKempenich]

@uranusjr This is genius!!

I just tested, it works as expected and feels much cleaner than my version.
For reference the zsh equivalent of .bash_profile is .zlogin: http://zsh.sourceforge.net/Intro/intro_3.html

Thanks for teaching me about _login vs interactive_ shells. I'm switching to your version 👍