pyenv-virtualenv icon indicating copy to clipboard operation
pyenv-virtualenv copied to clipboard

Failed to activate virtualenv

Open distobj opened this issue 3 years ago • 23 comments

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.

distobj avatar Aug 11 '21 18:08 distobj

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 https://github.com/pyenv/pyenv-virtualenv/issues/389 for discussion on what to do about that.

native-api avatar Aug 12 '21 21:08 native-api

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 -)"

distobj avatar Aug 13 '21 13:08 distobj

Figured out the possible cause: #402

muppetjones avatar Aug 13 '21 23:08 muppetjones

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

This is a wrong command. Check the README.

native-api avatar Aug 13 '21 23:08 native-api

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.

ciancolo avatar Aug 23 '21 10:08 ciancolo

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.

pohmelie avatar Aug 23 '21 10:08 pohmelie

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.

ciancolo avatar Aug 23 '21 10:08 ciancolo

For me it uses global version set with pyenv.

pohmelie avatar Aug 23 '21 10:08 pohmelie

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 -)"

pohmelie avatar Aug 23 '21 11:08 pohmelie

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:

https://github.com/pyenv/pyenv-virtualenv/blob/29fb3c7cd1a1fce154407ea728e2e2aa63a36544/bin/pyenv-virtualenv#L566

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:

https://github.com/pyenv/pyenv-virtualenv/blob/29fb3c7cd1a1fce154407ea728e2e2aa63a36544/bin/pyenv-virtualenv#L145-L147

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.

KostyaEsmukov avatar Aug 28 '21 21:08 KostyaEsmukov

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.

native-api avatar Oct 06 '21 23:10 native-api

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)"

andreagrandi avatar Dec 09 '21 15:12 andreagrandi

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 avatar Mar 29 '23 15:03 laur89

@laur89 yes, this still works for me.

pohmelie avatar Mar 29 '23 15:03 pohmelie

@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 avatar Mar 30 '23 12:03 laur89

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

pohmelie avatar Mar 30 '23 12:03 pohmelie

_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.

laur89 avatar Mar 30 '23 13:03 laur89

Are you sure comments in sytax are supported?

pohmelie avatar Mar 30 '23 13:03 pohmelie

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.

laur89 avatar Mar 30 '23 13:03 laur89

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 https://github.com/pyenv/pyenv/issues/2733

laur89 avatar Jun 17 '23 09:06 laur89

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

nicopicchio avatar Jul 24 '23 12:07 nicopicchio

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

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

laur89 avatar Jul 24 '23 14:07 laur89

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 -)"

nicopicchio avatar Jul 25 '23 13:07 nicopicchio