pyenv / pyenv-virtualenv

Further to encountering the same symptoms reported in this pyenv issue, I added "--path" to the "eval pyenv init" invocation in my .bashrc. While pyenv now uses the correct python executable, it no longer works with pyenv-virtualenv and a simple "pyenv activate foobar" reports the titular error.

This means that you haven't run eval "$(pyenv init -)" in the current shell. pyenv activate requires pyenv to be a shell function.

The current message is misleading as it doesn't tell you this. See #389 for discussion on what to do about that.

I am. This is the current pyenv section of my .bashrc

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
#eval "$(pyenv init -)"
eval "$(pyenv init - --path)"
eval "$(pyenv virtualenv-init -)"

Figured out the possible cause: #402

eval "$(pyenv init - --path)"

This is a wrong command. Check the README.

Hello, a my colleague finds this trick to activate Virtualenvs with Pyenv >= 2.0 .

Add the following row in file .profile (or similar):

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv virtualenv-init -)"
eval "$(pyenv init -)"

I think it is not the best way to do it but for now, it works.

It's strange, I see everything is fine in my konsole bash terminal (I mean auto activation of env), but in vscode builtin terminal auto activation does not work. @ciancolo, your solution did not help.

It's strange, I see everything is fine in my konsole bash terminal (I mean auto activation of env), but in vscode builtin terminal auto activation does not work. @ciancolo, your solution did not help.

For me it's fine. I'm using that in Ubuntu 20.04. For me, the problem was that the virtualenv looked like active, but the python used was the OS one.

For me it uses global version set with pyenv.

Don't know exactly what was the problem, but after upgrading (vscode upgraded too) and rebooting (since kernel update) everything is working fine. My .bashrc pyenv config looks like:

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

For me, the problem was that the virtualenv looked like active, but the python used was the OS one.

I was having the same issue with pyenv==2.0.5 and pyenv-virtualenv==1.1.5.

Strangely though python 3 venvs were working fine, but when I tried to create a 2.7 venv it was actually created using 3.9 (the system version):

Requirement already satisfied: setuptools in /Users/kostya/.pyenv/versions/2.7.18/envs/<...>/lib/python3.9/site-packages (57.4.0)
Requirement already satisfied: pip in /Users/kostya/.pyenv/versions/2.7.18/envs/<...>/lib/python3.9/site-packages (21.2.2)

It looks that the fallback to the system version is happening here:

pyenv-virtualenv/bin/pyenv-virtualenv

Line 566 in 29fb3c7

    
           pyenv-exec "${M_VENV_PYTHON_BIN:-python}" -m venv $QUIET $VERBOSE "${VIRTUALENV_OPTIONS[@]}" "${VIRTUALENV_PATH}" || STATUS="$?"

And the reason why it was happening seems to be the absense of both -m venv and virtualenv in my 2.7 version.

Actually, the virtualenv package was available (it was installed in 2.7.17 to the common site-packages dir ~/.local/lib/python2.7/site-packages), but the bin command virtualenv was only present in the 2.7.17 version. pyenv-virtualenv seems to be looking at its presence here:

pyenv-virtualenv/bin/pyenv-virtualenv

Lines 145 to 147 in 29fb3c7

    
           if [ -x "${prefix}/bin/virtualenv" ]; then 
        
             HAS_VIRTUALENV=1 
        
           fi

So I did pyenv shell 2.7.18; python -m pip install --upgrade --force-reinstall virtualenv to ensure that `pyenv prefix 2.7.18`/bin/virtualenv file exists and that solved the issue: the newly created 2.7.18 venvs were using 2.7.

Please see updated and hopefully clearer Pyenv shell setup instructions in https://github.com/pyenv/pyenv#readme
eval "$(pyenv virtualenv-init -)" should run in an rc file after eval "$(pyenv init -)" as before.

Don't know exactly what was the problem, but after upgrading (vscode upgraded too) and rebooting (since kernel update) everything is working fine. My .bashrc pyenv config looks like:
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

I came here to open an issue, but after I tried the above config, everything seems to be working for me too 🎉
Maybe the docs should we updated with these instructions?

My previous config was just:

eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

I was missing:

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"

Don't know exactly what was the problem, but after upgrading (vscode upgraded too) and rebooting (since kernel update) everything is working fine. My .bashrc pyenv config looks like:
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

Does this work for people still? Tried these in every possible combination/order but still can't get virtual envs to automatically load anymore. Note manual activation via pyenv activate <env-name> works fine.

@laur89 yes, this still works for me.

@pohmelie do you use bash? Had forgotten that eval "$(pyenv init --path)" was already included in ~/.profile, so that's why its addition to .bashrc made no difference.
Could you update pyenv and its plugins/submodules to latest version and verify it still functions a-ok?

@laur89
Yes, I'm on bash. Updated and everything is ok.

_pyenv_virtualenv_hook is the command added to shell's $PROMPT_COMMAND; looking at it, it's executing pyenv sh-activate. If I run it manually, it complains:

$ pyenv sh-activate
pyenv-virtualenv: version `system' is not a virtualenv
false

Any idea where it picks system up from? The project directory I'm in has:

$ cat .python-version 
#3.9.7
venv39

and as stated above, manually running pyenv activate venv39 does activate the venv.

Are you sure comments in sytax are supported?

Until now it's worked fine. Removing the commented line also doesn't change anything.
In short, looks like my issue is due to pyenv not reading version from .python-version file.

Trying to look bit more into this now. I discovered that new shell instances that are started work just fine, but not the one that was started at system startup. In the non-working shell, it looks like pyenv-version-name called from pyenv-exec is where the default and never-changing system value originates from:

PYENV_VERSION="$(pyenv-version-name)"

In working shells this logic path is not taken, as in pyenv-exec does not seem to be called at all during shell startup.

Comparing printenv | grep PYENV between good & bad shells:

Bad shell:

PYENV_HOOK_PATH=/home/laur/.pyenv/pyenv.d:/usr/local/etc/pyenv.d:/etc/pyenv.d:/usr/lib/pyenv/hooks:/home/laur/.pyenv/plugins/pyenv-virtualenv/etc/pyenv.d:/home/laur/.pyenv/plugins/pyenv-which-ext/etc/pyenv.d:/home/laur/.pyenv/pyenv.d:/usr/local/etc/pyenv.d:/etc/pyenv.d:/usr/lib/pyenv/hooks:/home/laur/.pyenv/plugins/pyenv-virtualenv/etc/pyenv.d:/home/laur/.pyenv/plugins/pyenv-which-ext/etc/pyenv.d
PYENV_SHELL=bash
PYENV_VERSION=system
PYENV_VIRTUALENV_INIT=1
PYENV_DIR=/home/laur
PYENV_ROOT=/home/laur/.pyenv

Good/working shell:

PYENV_SHELL=bash
PYENV_VIRTUALENV_INIT=1
PYENV_ROOT=/home/laur/.pyenv

Edit: my problem is specific to my system, it's to do with how I'm launching the problematic shell. See pyenv/pyenv#2733

Hi, wondering if there is a way to autoactivate virtualenv using zsh too?
I have been given a MacBook from work and the autoactivation does not work.
It works however on my debian machine

Hi, wondering if there is a way to autoactivate virtualenv using zsh too?

Best open a new issue. But did you check this?

Hi, wondering if there is a way to autoactivate virtualenv using zsh too?

Best open a new issue. But did you check this?

I have indeed. This is what is in my .zshrc file.

export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
export PATH=$PYENV_ROOT/shims:${PATH}
export PYENV_VIRTUALENV_DISABLE_PROMPT=1
eval "$(pyenv init --path)"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"

	if [ -x "${prefix}/bin/virtualenv" ]; then
	HAS_VIRTUALENV=1
	fi

Failed to activate virtualenv