On OSX 10.11.5, that came with Python 2.7.10.
I installed pyenv with homebrew, then added the two lines recommended to .zshrc
export PYENV_ROOT=/usr/local/var/pyenv
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
Then ran source ~/.zshrc. Then tried to install Python 3 and use it as the global:
pyenv install 3.5.2
pyenv global 3.5.2
Then confirmed the version pyenv which python returns /usr/local/var/pyenv/versions/3.5.2/bin/python.
However, running python -V still shows 2.7.10. Same problem with pyenv local 3.5.2
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
What does your $PATH look like after all this? It seems like something must be affecting it after pyenv.
I'm actually having the same issue on OSX 10.11.15 as well (installed with Homebrew, using zshell).
pyenv versions
system
* 2.7.10 (set by /Users/wpaul/.python-version)
and
pyenv which python
/usr/local/var/pyenv/versions/2.7.10/bin/python
Yet in the same shell:
python -V
Python 2.7.12
My $PATH has been polluted by RVM, but it has pyenv at the beginning:
/usr/local/var/pyenv/shims:/Users/wpaul/.rvm/gems/ruby-1.9.3-p551/bin:/Users/wpaul/.rvm/gems/ruby-1.9.3-p551@global/bin:/Users/wpaul/.rvm/rubies/ruby-1.9.3-p551/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/sbin:/Users/wpaul/.rvm/bin
My $PATH:
/Users/dbaron/.pyenv/shims:/Users/dbaron/.nvm/versions/node/v5.9.1/bin:/usr/local/bin:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Applications/eclipse:/usr/local/heroku/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/Library/Ruby/Gems/2.0.0/gems/travis-1.8.0/bin
I'm also using zsh with oh-my-zsh, could there be some different configuration required to make this work with zsh?
I added setopt shwordsplit to .zshrc and then it started working, based on this zsh doc.
But now even if I remove the shwordsplit option, its still working, so not entirely sure what made it start working. My .zshrc last few lines:
# added for pyenv
#To use Homebrew's directories rather than ~/.pyenv
export PYENV_ROOT="/usr/local/var/pyenv"
#To enable shims and autocompletion
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
Hmm, exact same result for me as well...
Just set it up on another machine (osx, zsh), and this time, even without setopt shwordsplit it's working. The only other thing I can think of is after installing via homebrew, the instructions said to add:
export PYENV_ROOT=/usr/local/var/pyenv
But then changing it to use quotes may have fixed it:
export PYENV_ROOT="/usr/local/var/pyenv"
First time user of pyenv & I just encountered this issue.
On latest version of OS X (10.11.6 as of this post). pyenv 20160726. zsh 5.2 from homebrew.
I noticed that after opening up a terminal, my path wasn't reflecting what I set it to be in my .zshenv file:
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/d10p/.cargo/bin:~/.nvm:/usr/local/var/pyenv/shims
But if I did an echo $PATH at the end of my .zshenv, it was giving me a different value - the one I was expecting:
/Users/d10p/.cargo/bin:~/.nvm:/usr/local/var/pyenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
I figured it must've been another file zsh was sourcing on startup that was changing my PATH. Using the ArchLinux wiki's page on Zsh, I discovered a few more files that zsh will source on startup.
For me, it ended up being /etc/zprofile that was causing the PATH mismatch. I commented out the files contents and after that, I was getting the correct version of Python from pyenv instead of MacOS's internal version.
I'm not sure if this is the same cause affecting some of you - some of the PATHs posted here look like they should work, while the result of my echo $PATH when opening a terminal already showed there was an issue there.
I had the same issue as d10p. It was caused by the path_helper call in /etc/zprofile. I solved it a little bit differently, just by putting pyenv initialization at the bottom of my local .zshrc.
Same issue as d10p. I solved it by add eval "$(pyenv init -)" in .zshrc
I had a different problem, with the same symptom. For some reason, pyenv was creating ~ (tilde) directories in my home directory, and within the versions and shims folders. I fixed it by specifying the following in my ~/.bashrc:
# Declaring PYENV_SHELL might be unnecessary
export PYENV_ROOT="$HOME/.pyenv"
export PYENV_SHELL="bash"
# To enable shims and autocompletion
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
Notably, don't do this, use $HOME instead:
export PYENV_ROOT="~/.pyenv"
I don't know why, but macOS hates it. I'm using macOS Sierra 10.12.6, and I've run into similar problems with other version managers that required .bashrc changes.
I solved it with adding the pyenv paths and pyenv init within ~/.zshrc instead of ~/.zshenv, because path_helper is loaded with etc/zprofile. This should maybe be part of the docs (e.g. a note about path_helper).
Having the same issue, anyone has a fix for this? thanks!
Macbook-Pro-3:~ user$ pyenv versions
system
* 2.7.6 (set by /Users/user/.python-version)
Macbook-Pro-3:~ user$ python --version
Python 2.7.10
Macbook-Pro-3:~ user$
*Update - None of the above suggested fixes work.
Looks like @obsoke found my problem too (https://github.com/pyenv/pyenv/issues/660#issuecomment-240532278). For reference, this was my zprofile:
⇒ cat /etc/zprofile
# system-wide environment settings for zsh(1)
if [ -x /usr/libexec/path_helper ]; then
eval `/usr/libexec/path_helper -s`
fi
Based on this StackOverflow:
The man page for path_helper opens with:
The path_helper utility reads the contents of the files in the directories /etc/paths.d and /etc/manpaths.d and appends their contents to the PATH and MANPATH environment variables respectively.
The crucial point here is that the path_helper utility is intended to add contents to an existing PATH setting, not replace them. (And in actuality, what it really does is prepend contents, not append them, which matters for PATH variables...)
While there wasn't much of interest in /etc/manpaths.d, it ALSO seems to be prepending the common system paths before all of my existing paths, which obviously messes with things:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:MYOTHERSTUFFHERE
The zsh startup order for sourced files is here:
This blog gives similar advice:
The weird part though is that zshrc SHOULD be getting sourced after zprofile, so this shouldn't be an issue.. but for whatever reason, for me it is.
Edit: After playing around a bit, it looks like using the 'antigen' pyenv loader may not play nicely with PYENV_ROOT when I set it to ~/.pyenv. Fixed by manually setting this env var and exporting it before calling eval "$(pyenv init - zsh)"
@IllyaMoskvin thanks buddy, you saved my day
Adding the following command in .bashrc resolved the issue for me.
eval "$(pyenv init -)"
@vaichidrewar
Adding the following command in .bashrc resolved the issue for me.
eval "$(pyenv init -)"
While this results in the correct local version of Python, it messes up the system python on mac:
$python3 -V gives the correct version but
$python -V results in 'no such file or directory', whereas it should normally link to Mac's system python 2.7. Why is that?
Always make sure you haven't (accidentally) installed Python via homebrew as well as this will mess with your pyenv installs.
Took me a good 2 hours now to find out that this was the problem in my case. I actually know not to install Python with brew, but, some other packages dependent on Python seem to have (auto-)installed it when I last upgraded them.
I seemed to be having this issue when setting up with High Sierra. For me this seemed like a $PATH issue, and in my case the shims were placed in my $HOME directory after installing via Homebrew.
Formatting my $PATH variable to have this before the default bin directories solved my issues:
export PATH="$HOME/.pyenv/shims:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Hopefully this saves someone some time.
I had a different problem, with the same symptom. For some reason, pyenv was creating
~(tilde) directories in my home directory, and within theversionsandshimsfolders. I fixed it by specifying the following in my~/.bashrc:# Declaring PYENV_SHELL might be unnecessary export PYENV_ROOT="$HOME/.pyenv" export PYENV_SHELL="bash" # To enable shims and autocompletion if which pyenv > /dev/null; then eval "$(pyenv init -)"; fiNotably, don't do this, use
$HOMEinstead:export PYENV_ROOT="~/.pyenv"I don't know why, but macOS hates it. I'm using macOS Sierra 10.12.6, and I've run into similar problems with other version managers that required
.bashrcchanges.
Thanks, it works for me on macOS Mojave 10.14.2.
I added this:
# To enable shims and autocompletion
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
Maybe my comment in this other issue could help somebody.
The issue that I had was in .bash_profile: I had originally installed the system Python with 'brew install'. This added a line into .bash_profile that set the PATH to the latest location of the system Python. The line in .bash_profile, which sets the PYTHON path, runs after 'source .bashrc'.
Later I installed pyenv, and added the eval to .bashrc to set the PATH, as recommended by pyenv. However, since .bashrc was sourced before the PATH was modified by .bash_profile, the system Python was in the PATH ahead of pyenv's path. The fix for this is to remove the PATH modification in .bash_profile, or move it ahead of 'source .bashrc'.
I had a different problem, with the same symptom. For some reason, pyenv was creating
~(tilde) directories in my home directory, and within theversionsandshimsfolders. I fixed it by specifying the following in my~/.bashrc:# Declaring PYENV_SHELL might be unnecessary export PYENV_ROOT="$HOME/.pyenv" export PYENV_SHELL="bash" # To enable shims and autocompletion if which pyenv > /dev/null; then eval "$(pyenv init -)"; fiNotably, don't do this, use
$HOMEinstead:export PYENV_ROOT="~/.pyenv"I don't know why, but macOS hates it. I'm using macOS Sierra 10.12.6, and I've run into similar problems with other version managers that required
.bashrcchanges.
Thank you! This solved it for me..
This thread has become a mashup of solutions to multiple problems and people posting "thank you" replies so I'm going to close and lock it.
While I appreciate the engagement, if the docs/wiki/readme are wrong, please fix them with PRs or submit a new issue to request that they be changed. This will help people get the setup right the first time and avoid future issues being created when new users don't search the old issues for solutions or can't find it when they do because it's buried in an unrelated thread.
Most helpful comment
Same issue as d10p. I solved it by add
eval "$(pyenv init -)"in.zshrc