Pyenv: Pyenv can't find system python (3.8) on Ubuntu 20.04

[lysnikolaou]

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 issues. You should look for 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 plugins.
  
  
  
  • This repository is maintaining pyenv and the default python-build plugin only. Please refrain from reporting issues of other plugins here.
  
  

Description

• Platform information: Ubuntu Linux 20.04
• OS architecture: x86-64
• pyenv version: 1.2.18
• Python version: 3.8.2
• C Compiler information: gcc 9.3.0
• Please attach verbose build log as gist: https://gist.github.com/lysnikolaou/53519db559370ca105999fb9f3dbef45

pyenv can't find system-installed Python on Ubuntu 20.04, where the default Python version is now 3.8. I'm not sure if this is a pyenv problem, but I guess it is, since the error message I'm getting says that pyenv can't find any python executable in my PATH, although there certainly is one.

Some more info about this:

➜  ~ pyenv versions                               
* 3.8.2 (set by /home/lysnikolaou/.pyenv/version)
  3.8-dev
  3.9-dev
➜  ~ pyenv global system
pyenv: system version not found in PATH

But system Python is there:

➜  ~ ls /usr/bin | grep python3.8
python3.8
➜  ~ /usr/bin/python3.8
Python 3.8.2 (default, Apr 27 2020, 15:53:34) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello, world")
hello, world

And /usr/bin is certainly in my PATH:

➜  ~ echo $PATH         
/usr/local/opt/sphinx-doc/bin:/usr/local/sbin:/home/lysnikolaou/.pyenv/shims:/home/lysnikolaou/.pyenv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

[thiras]

I confirm the bug

[joshfriend]

You want pyenv to come after /usr/bin in your path probably

[thiras]

@joshfriend I did not change my path manually. Just installed through pyenv-installer. So it's a bug.

It's also urgent bug. Because it's impossible to turn back to system python now with pyenv

[lysnikolaou]

You want pyenv to come after /usr/bin in your path probably

If that's the case, shouldn't the README be updated to indicate the PATH should be set to "$PATH:$PYENV_ROOT/bin"?

[lysnikolaou]

@joshfriend Do you actually mean $PYENV_ROOT/bin or $PYENV_ROOT/shims?

[Ksancha]

I can confirm the bug.

In fact, I can't even see the system python that is currently running

➜ ~$ pyenv versions  
3.6.10
3.7.7
 ```
And the default python is

➜ ~$ python -V
3.8.2
```

Please note I had to alias python to python3, as there is no python on Ubuntu.

[TKaluza]

I have the same problem.
What would be the best workaround?

[ghost]

It seems like there are multiple issues going on here, so I'll try to clarify.

1. System python installations are not detected by pyenv:

I was able to partially replicate the error in Linux Mint 19.3. The system Python 2 install was detected but the Python 3 version was not, which for me isn't a big deal. In my opinion, system installations of Python should be reserved for internal OS libraries and third-party packages. The user shouldn't really care about using the system installations of Python.

I'm not trying to nullify the error by saying that "you shouldn't be using the system installation anyway". Perhaps there are good use cases that I'm missing and don't completely understand. If someone is willing to clarify then we can proceed with an appropriate bug fix.

1. The README is misleading:

Yes, I agree there. It needs to be cleaned up a bit and reorganized. I found it cumbersome to use pyenv right off the bat and had to do some manual configuration to make it completely usable and get it to where I wanted it.

1. This is a critical bug and irreversible, leaving the OS in an unusable state:

No, that's not true at all. You can still keep using the system version of python simply by uninstalling pyenv. I don't think you even need to remove any of the environment variables or update $PATH.

[cqql]

The problem on my fresh Ubuntu 20.04 installation is that there is no python executable. /usr/bin only has python2 and python3 but pyenv checks for python to determine if a system version is available, see e.g. in line 105 of pyenv-versions.

As a workaround create a python executable yourself, for example with ln -s /usr/bin/python3 /usr/bin/python.

[iamdirk]

The problem on my fresh Ubuntu 20.04 installation is that there is no python executable. /usr/bin only has python2 and python3 but pyenv checks for python to determine if a system version is available, see e.g. in line 105 of pyenv-versions.

As a workaround create a python executable yourself, for example with ln -s /usr/bin/python3 /usr/bin/python.

Simply editing the L105 call from 'pyenv-which python' to 'pyenv-which python3' also resulted in 'pyenv versions' showing the single bundled Ubuntu 20.04 LTS python 3.8 install under 'system'.
The functionality of the L105 starting statement seems pretty isolated to printing a variable so editing it should not break anything else™.

This is probably not as clean as the sym link solution above, and also doesn't solve showing multiple system installed pythons as it simple moves the problem from not showing a 'python3' call dependent install to not showing a 'python' call dependent install. However if for whatever reason a sym link solution is not possible maybe this can help.

[hennit]

I believe there is an official workaround for the missing system python which is sudo apt install python-is-python3
It did the trick for me

[ghost]

@hennit python-is-python3 just creates a symlink, which fixes the problem--yes.

Did the /usr/bin/python symlink ever exist? I think that's dependent on which Linux distro you're using.

[mrsarm]

I have the same issue, but the workaround is pretty simple, just edit by hand the configuration file that pyenv use to store the settings you passed when executed pyenv global ....

So I you tried the following: pyenv global 2.7.18 system, try instead to save the following content in the ~/.pyenv/version file:

2.7.18
system

Then to take effect the change you need to run a new shell console, and future new terminals will also get that configuration.

Also worth to note that if you try to setup one version of Python 2 and one of Python 3, you should setup the Python 2 version first (first line at ~/.pyenv/version), because it is the default version assigned to python (without the 2 or the 3 at the end), and according with some PEP that I don't know the number, when you have the two major versions of Python co-existing in the same system, python should be an alias of python2, not python3.

[YusongLeng]

The problem on my fresh Ubuntu 20.04 installation is that there is no python executable. /usr/bin only has python2 and python3 but pyenv checks for python to determine if a system version is available, see e.g. in line 105 of pyenv-versions.
As a workaround create a python executable yourself, for example with ln -s /usr/bin/python3 /usr/bin/python.

Simply editing the L105 call from 'pyenv-which python' to 'pyenv-which python3' also resulted in 'pyenv versions' showing the single bundled Ubuntu 20.04 LTS python 3.8 install under 'system'.
The functionality of the L105 starting statement seems pretty isolated to printing a variable so editing it should not break anything else™.

This is probably not as clean as the sym link solution above, and also doesn't solve showing multiple system installed pythons as it simple moves the problem from not showing a 'python3' call dependent install to not showing a 'python' call dependent install. However if for whatever reason a sym link solution is not possible maybe this can help.

Thanks for the trick! By editing L105, system will be displayed in the list resulted from pyenv versions. However, system still cannot be activated by calling pyenv global system, and the error info is pyenv: system version not found in PATH. Luckily, PR #1655 solves this issue! ;)

[thiras]

Is there any ETA for the #1655 ?

[rober5566a]

The problem on my fresh Ubuntu 20.04 installation is that there is no python executable. /usr/bin only has python2 and python3 but pyenv checks for python to determine if a system version is available, see e.g. in line 105 of pyenv-versions.

As a workaround create a python executable yourself, for example with ln -s /usr/bin/python3 /usr/bin/python.

This way is work for me!! type sudo ln -s /usr/bin/python3 /usr/bin/python.
all packages are come back!
Thanks!

[kiddick]

Faced with that issue too. Used sudo ln -s /usr/bin/python3 /usr/local/bin/python workaround on MacOS

[rohitb1023]

The simple workaround I did in ubuntu 20.04 is to install a package called python-is-python3. You can also do it by using sudo apt install python-is-python3

[borfast]

@kiddick and @rohitb1023, your solutions are pretty much the same thing (what the python-is-python3 package does is create a symlink as the one @kiddick mentioned) but be careful, as they may not be the best approach for now. Some software that is not compatible with Python 3 may have been written under the assumption that the python executable is Python 2. If this is the case and you make the aforementioned symlink change, the software will run under Python 3 "thinking" it is Python 2 and it will probably break.

[Nycticorax]

The problem on my fresh Ubuntu 20.04 installation is that there is no python executable. /usr/bin only has python2 and python3 but pyenv checks for python to determine if a system version is available, see e.g. in line 105 of pyenv-versions.

As a workaround create a python executable yourself, for example with ln -s /usr/bin/python3 /usr/bin/python.

Best workaround so far. On openSUSE's distros it also happens that python is not a valid alias by default.