Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to activate virtualenv #401

Open
distobj opened this issue Aug 11, 2021 · 23 comments
Open

Failed to activate virtualenv #401

distobj opened this issue Aug 11, 2021 · 23 comments

Comments

@distobj
Copy link

distobj commented Aug 11, 2021

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.

@native-api
Copy link
Member

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.

@distobj
Copy link
Author

distobj commented Aug 13, 2021

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

@muppetjones
Copy link

Figured out the possible cause: #402

@native-api
Copy link
Member

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

This is a wrong command. Check the README.

@ciancolo
Copy link

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.

@pohmelie
Copy link

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.

@ciancolo
Copy link

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.

@pohmelie
Copy link

For me it uses global version set with pyenv.

@pohmelie
Copy link

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

@KostyaEsmukov
Copy link

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-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:

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.

@native-api
Copy link
Member

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.

@andreagrandi
Copy link

andreagrandi commented Dec 9, 2021

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

@laur89
Copy link

laur89 commented Mar 29, 2023

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.

@pohmelie
Copy link

@laur89 yes, this still works for me.

@laur89
Copy link

laur89 commented Mar 30, 2023

@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?

@pohmelie
Copy link

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

@laur89
Copy link

laur89 commented Mar 30, 2023

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

@pohmelie
Copy link

Are you sure comments in sytax are supported?

@laur89
Copy link

laur89 commented Mar 30, 2023

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
Copy link

laur89 commented Jun 17, 2023

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

@nicopicchio
Copy link

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

@laur89
Copy link

laur89 commented Jul 24, 2023

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

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

@nicopicchio
Copy link

nicopicchio commented Jul 25, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants