pipenv shell getting wrong python version

[shacker]

pipenv is installed for python3 only. I specify python3 when creating the environment in a new empty directory. pipenv run python --version correctly reports python3. But when I run pipenv shell from within that same directory, I get

$ python --version
Python 2.7.10

Here are complete steps, showing install locations and versions:

[shacker@shackmac dev]$ mkdir foobar
[shacker@shackmac dev]$ cd foobar
[shacker@shackmac foobar]$ which pipenv
/Library/Frameworks/Python.framework/Versions/3.6/bin/pipenv
[shacker@shackmac foobar]$ pipenv --version
pipenv, version 2018.05.18
[shacker@shackmac foobar]$ pipenv --python 3.6
Creating a virtualenv for this project…
Using /Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6m (3.6.3) to create virtualenv…
⠋Running virtualenv with interpreter /Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6m
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/shacker/.local/share/virtualenvs/foobar-labP-NDG/bin/python3.6m
Also creating executable in /Users/shacker/.local/share/virtualenvs/foobar-labP-NDG/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/shacker/.local/share/virtualenvs/foobar-labP-NDG
Creating a Pipfile for this project…
[shacker@shackmac foobar]$ pipenv run python --version
Python 3.6.3
[shacker@shackmac foobar]$ pipenv shell
Spawning environment shell (/bin/bash). Use 'exit' to leave.

bash-3.2$ . /Users/shacker/.local/share/virtualenvs/foobar-labP-NDG/bin/activate
/Users/shacker/dev/foobar
bash-3.2$ python --version
Python 2.7.10
bash-3.2$ ls -l
total 8
drwxr-xr-x   3 shacker  staff   102 May 22 08:03 ./
drwxr-xr-x  31 shacker  staff  1054 May 22 08:03 ../
-rw-r--r--   1 shacker  staff   138 May 22 08:03 Pipfile
bash-3.2$ echo $PIPENV_VENV_IN_PROJECT
[no return value]

This is only happening on one of my machines -- others are fine. But I can't figure out what's different about this environment to cause this. Thanks for any suggestions.

[kennethreitz42]

this sounds like a problem with your .bashrc or similar. I'd recommend investigating that.

[shacker]

Ahah - $ pipenv shell --fancy does the right thing, while omitting --fancy leaves me with the wrong python version. Possibly related to this discussion from a year ago? I guess that means I have an "elegantly configured shell." But if so, it's biting me.

With --fancy, it pushes the venv path to the top of PATH:

echo $PATH
/Users/shacker/.local/share/virtualenvs/foo5-4tDUoJty/bin:

That is not present in PATH if I omit --fancy.

Hard to tell whether I'm looking at a bug or a feature here. Should I file it?

[uranusjr]

I would bet real money on your bashrc not being configured correctly.

[shacker]

I was about to say "The only thing in my .bashrc are bash aliases." Which is true, but then I commented them all out and tried again, and pipenv shell worked properly! Took a closer look at those aliases and found something (leftover from some online tip I found years ago) that made me wonder. Commented out just these two lines:

alias .='pwd'
alias ..='cd ..'

and sure enough, that was the culprit. Interesting. I don't use that alias anyway, good riddance. File under "never replace existing system commands via aliases." Thanks for your time guys, appreciated.

[uranusjr]

Ah I think it’s the . one that caused trouble. . is a shell-built-in that sources files (the same as source in Bash, but works for all Bourne-derived shells). Aliasing it to something else is looking for trouble :)

The reason “fancy” works is because the two modes use different initialisation strategies. Non-fancy (aka compat) uses . or source to inject things into the new shell; fancy uses environment variable manipulation from Python (i.e. modifying os.environ).

p.s. Aliasing .. is fine IMO.