Hi, I updated my Homebrew install and I'm now getting an info message displayed whenever I'm changing into directories that have a .python-version file in them (I'm guessing? I'm not entirely sure on what triggers the behaviour).

It says: pyenv-virtualenv: prompt changing will be removed from future release. configureexport PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.` but it's not really clear to me from that message how the prompt will change in the future and how that variable is supposed to work, i.e. what its expected behaviour is.

I added the var to my shell file just to try it out, and the resulting prompt is definitely not what I want, as it seems to get stuck in a mode where it always displays the currently activated virtualenv, regardless of where I am in my file system.

Re: what's going to change: Will only the active/deactive messages disappear? Or both that and the prompt prefix that displays the virtualenv's name, like so (myvirtualenv) mymachine:~$?

And a general question, not directly related to this issue: are you accepting PRs for improving documentation? Because I'd really like to add a bit of info to this repo's README that would've saved me lots of time trying to figure out a particular problem I had.

My .zshenv contains

export PYENV_ROOT="$HOME"/.pyenv
export PATH="$PYENV_ROOT"/bin:"$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
  eval "$(pyenv init -)"
fi

which works fine, however, if I simply add eval "$(pyenv virtualenv-init -)" I keep receiving the message zsh: command not found: pyenv

Pyenv and pyenv-virtualenv work perfectly fine and if I enter exec "$SHELL" the message goes away until I restart the terminal so I'm sure what the issue is.

I'm running Arch Linux, Zsh 5.4.2-1, tmux 2.5-3, termite 12-2, and the master branch of both pyenv and pyenv-virtualenv pulled today.

I'm showing you the steps I use to create a virtualenv based on miniconda. Finally you will see that the virtualenv was created but I can't access to it.

1.0. Check my initial pyenv versions:

$ pyenv versions
* system (set by /home/oscar/.python-version)
2.7.9
3.5.1

1.1 Install miniconda:

$ pyenv install miniconda3-4.0.5

$ pyenv versions
* system (set by /home/oscar/.python-version)
  2.7.9
  3.5.1
  miniconda3-4.0.5

1.2. Create the venvtest virtualenv based on miniconda:

$ pyenv virtualenv miniconda3-4.0.5 venvtest

$ pyenv versions
* system (set by /home/oscar/.python-version)
  2.7.9
  3.5.1
  miniconda3-4.0.5
  miniconda3-4.0.5/envs/venvtest
  venvtest

When I want to check if the virtualenv was created, It doesn't show it. So I can't no access to it :cry:

$ pyenv virtualenvs
  miniconda3-4.0.5 (created from /home/oscar/.pyenv/versions/miniconda3-4.0.5)

$ pyenv activate ... (autocompleting)
--help            miniconda3-4.0.5  --unset 

Please, I hope you can help me.

I am trying to setup a virtualenv with --system-site-packages to use compiled/pre-built packages, and noticed that e.g. ipython fails to run with:

% pyenv virtualenv --system-site-packages 3.4.2 paperwork3
...
% ipython
pyenv: ipython: command not found

The `ipython' command exists in these Python versions:
...

Trying to install it skips it, because it appears to be installed already.

Could pyenv somehow handle this, especially after trying to (re-)install it?

Is it possible to have a post install hook so that every time a new virtualenv is created a package is installed too?

The use case is simple: i'd like - in the same way pip is installed - to have iPython installed automatically with every pyenv virtualenv created.

Hi,

I have been messing around with this for a few minutes and I can't quite figure out what the issue is. So I made a virtualenv to test out pyechonest for my brother, and once I was done I went to delete the virtualenv. First I simply deleted the directory containing the virtualenv. I have done this in the past and it has worked fine.

Now I get spammed with the following messages every time I execute any command in the terminal:

pyenv: version `echonest2' is not installed
pyenv: version `echonest2' not installed
pyenv: version `echonest2' is not installed

echonest2 is the name of the virtualenv that I created.

I have also tried using pyenv uninstall echonest2 and that didn't seem to help either. The only way I can get these messages to stop showing up is to take the stuff related to pyenv out of my .bashrc. I have even tried completely uninstalling pyenv (by deleting the .pyenv) directory, and that still didn't solve it.

Hopefully this makes sense.

Thanks!

P.S. I am running Arch Linux if that makes any difference.

When running $ eval "$(pyenv virtualenv-init -)", I always get this error message:

Failed to deactivate virtualenv.

Perhaps pyenv-virtualenv has not been loaded into your shell properly.
Please restart current shell and try again.

For some reason, I can still use it on the same shell I installed it in, but not any other shell. How do I load up pyenv-virtualenv properly? Note: I Installed it using Homebrew.

I just realised I have issues with my virtualenv:

$ python
-bash: /Users/ncopty/.pyenv/versions/finprod/bin/python: No such file or directory

$ ~/.virtualenvs/finprod/bin/python
Python 2.7.2 (default, Jul  2 2014, 14:30:17) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.34.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

Which one is the correct one and why do I have two?

while using any pip command I'm getting

/home/neurlap/.pyenv/plugins/pyenv-pip-rehash/libexec/pip: line 20: 24753 Segmentation fault      (core dumped) "$PYENV_COMMAND_PATH" "$@"

@native-api any help?

Hey there Yuu, hope you're well :smile:

Since some of the latest commits, I've been having quite a few major problems with this extension I'm afraid.

My test system is a fresh install of Ubuntu Server 12.04 with the regular bash shell.

This output should explain the problems :smile:

[email protected]:~$ pyenv versions
* system (set by /home/fots/.pyenv/version)
  2.7.7
  3.4.1
[email protected]:~$ python -V
Python 2.7.3
[email protected]:~$ pyenv global 2.7.7
[email protected]:~$ python -V
Python 2.7.7
[email protected]:~$ pyenv virtualenv newproject
New python executable in /home/fots/.pyenv/versions/newproject/bin/python
Installing setuptools, pip...done.
[email protected]:~$ pyenv activate newproject
(newproject)[email protected]:~$ python -V
Python 2.7.3
(newproject)[email protected]:~$ pyenv deactivate
(newproject)[email protected]:~$ unset PYENV_VERSION
[email protected]:~$ pyenv virtualenv 2.7.7 newproject2
New python executable in /home/fots/.pyenv/versions/newproject2/bin/python
Installing setuptools, pip...done.
[email protected]:~$ pyenv activate newproject2
(newproject2)[email protected]:~$ python -V
Python 2.7.3
(newproject2)[email protected]:~$

So in summary:

• Creating a virtualenv always uses the system version of Python
• Deactivating a virtualenv no longer correctly unsets the PYENV_VERSION environment variable

Your help would be greatly appreciated Fotis

After creating a virtualenv with:

pyenv virtualenv 3.5.3 myenv

I'm not able to run tox with this ini file:

[tox]
envlist = py35

[testenv]
commands =
    pytest {posargs: --pep8 --pylint}

deps = .[test]

The following error appears:

ERROR: InvocationError: Failed to get version_info for python3.5: b"pyenv: python3.5: command not found\n\nThe `python3.5' command exists in these Python versions:\n  3.5.3\n\n"

After checking my virtualenv it's clear that it doesn't contain a python3.5 symlink.

(myenv) ➜  ~ ll /home/stefanga/.pyenv/versions/myenv/bin/      
total 32K
-rw-r--r-- 1 stefanga axusers 2.2K Mar  3 13:06 activate
-rw-r--r-- 1 stefanga axusers 1.3K Mar  3 13:06 activate.csh
-rw-r--r-- 1 stefanga axusers 2.4K Mar  3 13:06 activate.fish
-rwxr-xr-x 1 stefanga axusers  276 Mar  3 13:06 easy_install
-rwxr-xr-x 1 stefanga axusers  276 Mar  3 13:06 easy_install-3.5
-rwxr-xr-x 1 stefanga axusers  248 Mar  3 13:06 pip
-rwxr-xr-x 1 stefanga axusers  248 Mar  3 13:06 pip3
-rwxr-xr-x 1 stefanga axusers  248 Mar  3 13:06 pip3.5
lrwxrwxrwx 1 stefanga axusers   47 Mar  3 13:06 python -> /home/stefanga/.pyenv/versions/3.5.3/bin/python
lrwxrwxrwx 1 stefanga axusers    6 Mar  3 13:06 python3 -> python

After creating the python3.5 -> python symlink manually tox executed without any errors.

Shouldn't all executables (python, pythonx and python x.y) be available in the virtualenv?

I'm running Mac 10.9.5 and i did the installation as below:

brew install pyenv
eval "$(pyenv init -)" >> ~/.bashrc
brew install pyenv-virtualenv
eval "$(pyenv virtualenv-init -)" >> ~/.bashrc

The installation home is all under

pyenv versions
* system (set by /usr/local/opt/pyenv/version)
  3.4.2
  ra1

[[email protected] in ~]# ll /usr/local/opt/pyenv*
lrwxr-xr-x  1 dani  admin    24B Oct 22 16:27 /usr/local/opt/pyenv -> ../Cellar/pyenv/20141012
lrwxr-xr-x  1 dani  admin    35B Oct 22 16:38 /usr/local/opt/pyenv-virtualenv -> ../Cellar/pyenv-virtualenv/20141012

I read the other issues - #47 , #48, #32 , #33 and i've followed the same steps as in #32 (i get this are the manual steps)

[[email protected] in ~]# pyenv versions
* system (set by /usr/local/opt/pyenv/version)
  3.4.2
  ra1
[[email protected] in ~]# python -V
Python 2.7.6
[[email protected] in ~]# echo PYENV_ACTIVATED
PYENV_ACTIVATED
[[email protected] in ~]# echo $PYENV_ACTIVATED

[[email protected] in ~]# echo $PYENV_DEACTIVATED

[[email protected] in ~]# echo $PYENV_VIRTUALENV_INIT
1
[[email protected] in ~]# pyenv activate ra1
(ra1) [[email protected] in ~]# python -V
Python 3.4.2
(ra1) [[email protected] in ~]# echo $PYENV_ACTIVATED

(ra1) [[email protected] in ~]# echo $PYENV_DEACTIVATED

(ra1) [[email protected] in ~]# echo $PYENV_VERSION
ra1
(ra1) [[email protected] in ~]# pyenv deactivate
[[email protected] in ~]# echo $PYENV_VERSION
ra1
[[email protected] in ~]# echo $PYENV_DEACTIVATED

[[email protected] in ~]# echo $PYENV_ACTIVATED

[[email protected] in ~]# pyenv version
ra1 (set by PYENV_VERSION environment variable)
[[email protected] in ~]# pyenv versions
  system
  3.4.2
* ra1 (set by PYENV_VERSION environment variable)
[[email protected] in ~]#

BUT because the above behavior, when i'm trying to uninstall the virtual env i get this error

[[email protected] in ~]# pyenv uninstall ra1
pyenv: remove /usr/local/opt/pyenv/versions/ra1? y
[[email protected] in ~]# pyenv versions
pyenv: version `ra1' is not installed
  system
  3.4.2

In #47 you mentioned,

As you mentioned, PYENV_DEACTIVATED should not persist after automatically triggered deactivation. I'll try to fix it in #47.

hence my question: _what is the working flow for the auto activation/ deactivation? Do i need to be inside the PYENV_ROOT in order for auto activation to kick in?_

In addition to this issue, according to the README file, the pyenv-virtualenv should be registered as a plugin inside pyenv, is this a bug in the brew formula's installation?

[[email protected] in ~]# ll /usr/local/opt/pyenv/plugins/
total 8
lrwxr-xr-x  1 dani  admin    61B Oct 22 16:27 python-build -> /usr/local/Cellar/pyenv/20141012/default-plugins/python-build

Too many issues will kill our team's development velocity, drastically. Make sure you have checked all steps below.

Prerequisite

• [x] Make sure your problem is not listed in the common build problems.
• [ x Make sure no duplicated issue has already been reported in the pyenv-virtualenv issues. You should look in closed issues, too.
• [x] Make sure you are not asking us to help solving your specific issue.
  • GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like Gitter, StackOverflow, etc.
• [x] Make sure your problem is not derived from packaging (e.g. Homebrew).
  • Please refer to the package documentation for the installation issues, etc.
• [x] Make sure your problem is not derived from other plugins.
  • This repository is maintaining the pyenv-virtualenv plugin only. Please refrain from reporting issues of other plugins here.

Description

• [x] Platform information (e.g. Ubuntu Linux 20.04): macOS 11 Big Sur
• [x] OS architecture (e.g. amd64): arm64 & x86_64
• [x] pyenv version: 2.3.9
• [x] pyenv-virtualenv version: 1.2.0
• [x] Python version: 3.11.1

 "$(pyenv init -)" && pyenv virtualenvs
  /usr/bin/readlink: illegal option -- f

Hello. macOS Big Sur does not support readlink -f. Recent changes in https://github.com/pyenv/pyenv-virtualenv/commit/c4de2555b7343c95a3380dece3098eaf3baa4e73 have fixed build errors for newer versions of macOS, but Big Sur cannot handle this. Is Big Sur still a supporterd OS?

Relevant Homebrew CI run with the failures: https://github.com/Homebrew/homebrew-core/actions/runs/3844517040/jobs/6561365032

Activate virtualenv Some external tools (e.g. jedi) might require you to activate the virtualenv and conda environments.

If eval "$(pyenv virtualenv-init -)" is configured in your shell, pyenv-virtualenv will automatically activate/deactivate virtualenvs on entering/leaving directories which contain a .python-version file that contains the name of a valid virtual environment as shown in the output of pyenv virtualenvs (e.g., venv34 or 3.4.3/envs/venv34 in example above) . .python-version files are used by pyenv to denote local Python versions and can be created and deleted with the pyenv local command.

• For example:：The virtual space name is my-virtual-env-2.7.10，Create a file named .python-versionin the virtual space folder my-virtual-env-2.7.10, and add the text of the micro virtual space name my-virtual-env-2.7.10

echo "my-virtual-env-2.7.10" >> $HOME/.pyenv/versions/2.7.10/envs/my-virtual-env-2.7.10/.python-version

You can also activate and deactivate a pyenv virtualenv manually:

pyenv activate <name>
pyenv deactivate

When a new Python version is released, I want to be able to migrate my virtualenv to the newer version without the need of reinstalling all the dependencies.

I want to be able to move it back to the previous/older versions too when needed

pyenv-virtualenv not auto-resolve python version like pyenv can (for example, now, pyenv install 3.10 will install current latest 3.10.8) https://github.com/pyenv/pyenv#prefix-auto-resolution

Command pyenv virtualenv 3.10 venv will create folder $PYENV_ROOT/versions/3.10/envs/venv instead of expected $PYENV_ROOT/versions/3.10.8/envs/venv

This also will break pyenv auto-resolve option, because even after delete virtual environment folder, $PYENV_ROOT/versions/3.10 will exist Related pyenv issue: https://github.com/pyenv/pyenv/issues/2533

NB: Also, I've faced fork-bomb problem somehow with this, when delete one of environments, caused by pyenv sh-activate in eval "$(pyenv virtualenv-init -)", but I didn't investigate this deeply, just completely remove $PYENV_ROOT and recreate it.

Prerequisite

• [x] Make sure your problem is not listed in the common build problems.
• [x] Make sure no duplicated issue has already been reported in the pyenv-virtualenv issues. You should look in closed issues, too.
• [x] Make sure you are not asking us to help solving your specific issue.
  • GitHub issues is opened mainly for development purposes. If you want to ask someone to help solving your problem, go to some community site like Gitter, StackOverflow, etc.
• [x] Make sure your problem is not derived from packaging (e.g. Homebrew).
  • Please refer to the package documentation for the installation issues, etc.
• [x] Make sure your problem is not derived from other plugins.
  • This repository is maintaining the pyenv-virtualenv plugin only. Please refrain from reporting issues of other plugins here.

Description

• Platform information: openSUSE Tumbleweed
• OS architecture (e.g. amd64): amd64
• pyenv version: 2.3.6
• pyenv-virtualenv version: 1.1.5
• Python version: 2.7.18, 3.10.8
• virtualenv version (if installed): none

Pyenv is not deactivating from virtual environment: Python 3.10.6

Description

• [ ] Platform information (e.g. Ubuntu Linux 20.04): macOS Monterey
• [ ] OS architecture (e.g. amd64): M1
• [ ] pyenv version: 2.3.5
• [ ] pyenv-virtualenv version: 1.1.5
• [ ] Python version: 3.10.6
• [ ] virtualenv version (if installed):
• [ ] Please attach the debug log of a faulty Pyenv invocation as a gist

(pysyft_0.7.0) [email protected] Infrastructure_as_code % 
pyenv deactivate
(pysyft_0.7.0) mac@ user1-MacBook-Pro Infrastructure_as_code % 
(pysyft_0.7.0) mac@ user1-MacBook-Pro Infrastructure_as_code % 

Looked into similar issues before raising current issue. Hope to get some help!

When a pyenv virtualenv is created with system-site-packages enabled, console scripts installed in the parent pyenv version are invoked using the parent's environment, not the current virtual environment, and cannot load packages installed in the virtualenv.

Reproduction:

Create a venv from a parent version that has packages with console scripts. Here, package pyright has a console script.

> pyenv virtualenv --system-site-packages 3.10.5 foo
> pyenv shell foo
foo > pyenv which pyright
/Users/tmiller/.pyenv/versions/3.10.5/bin/pyright

We pip install a package into the venv.

foo > pip install kopf
Looking in indexes: https://artifacts.mitre.org/artifactory/api/pypi/python/simple
Collecting kopf
  Downloading https://artifacts.mitre.org/artifactory/api/pypi/python/packages/packages/80/eb/e82f3e249db2ecd06aeb42eb4209ea295a00a98b9277bff13901e99ddeda/kopf-1.35.6-py3-none-any.whl (205 kB)
[...]

When invoked, pyright parses code and imports, but can't find the package in the venv.

foo > pyright ~/projects/foo
No configuration file found.
No pyproject.toml file found.
stubPath /Users/tmiller/typings is not a valid directory.
Assuming Python platform Darwin
Searching for source files
Found 1 source file
pyright 1.1.269
/Users/tmiller/projects/foo/bar.py
  /Users/tmiller/projects/foo/bar.py:3:8 - error: Import "kopf" could not be resolved (reportMissingImports)
1 error, 0 warnings, 0 informations
Completed in 0.596sec

When the console script is invoked as a module entry point, the import is resolved because python is executed in the venv.

foo > python -m pyright ~/projects/foo/
No configuration file found.
No pyproject.toml file found.
stubPath /Users/tmiller/typings is not a valid directory.
Assuming Python platform Darwin
Searching for source files
Found 1 source file
pyright 1.1.269
/Users/tmiller/projects/foo/bar.py
  /Users/tmiller/projects/foo/bar.py:6:2 - error: Argument of type "(namespace: Unknown, name: Unknown, resource: Unknown, **_: Unknown) -> dict[tuple[Unknown, Unknown], Unknown]" cannot be assigned to parameter of type "IndexingFn"
    Type "(namespace: Unknown, name: Unknown, resource: Unknown, **_: Unknown) -> dict[tuple[Unknown, Unknown], Unknown]" cannot be assigned to type "IndexingFn"
      Function accepts too many positional parameters; expected 3 but received 15 (reportGeneralTypeIssues)
1 error, 0 warnings, 0 informations
Completed in 0.82sec

Prerequisite

• [x] Make sure your problem is not listed in the common build problems.
• [x] Make sure no duplicated issue has already been reported in the pyenv-virtualenv issues. You should look in closed issues, too.

There are a couple of close issues, but nothing really seemed to match.

• [x] Make sure you are not asking us to help solving your specific issue.
• [x] Make sure your problem is not derived from packaging (e.g. Homebrew).
• [x] Make sure your problem is not derived from other plugins.

Description

• [x] Platform information (e.g. Ubuntu Linux 20.04):
• [x] OS architecture (e.g. amd64):

Darwin yadda 20.6.0 Darwin Kernel Version 20.6.0: Tue Jun 21 20:50:28 PDT 2022; root:xnu-7195.141.32~1/RELEASE_X86_64 x86_64

• [x] pyenv version:

pyenv 2.3.1-20-g572a8bcf

• [x] pyenv-virtualenv version:

pyenv-virtualenv 1.1.5 (python -m venv)

• [x] Python version:

All.

• [x] virtualenv version (if installed):

N/A

• [x] Please attach the debug log of a faulty Pyenv invocation as a gist

https://gist.github.com/Cerebus/bf0a32edd99d6d8c00a29401628771f8