Pyenv not properly working on Armbian. Possible bug?

[lliendo]

Hi there,

I'm using Armbian on the Pine RockPro64, uname -a reports:

Linux rockpro64 5.10.60-rockchip64 #21.08.1 SMP PREEMPT Wed Aug 25 18:56:55 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux

I've installed pyenv both through the manual instructions (cloning the repo and then updating .bashrc) and also through the installer (using the curl call mentioned in https://github.com/pyenv/pyenv-installer). For both options something weird is happening, and unable to clearly see what the problem is. Here are for the steps that I've done to try to install Python 3.9.0 (after either cloning or doing the curl installation):

1. Update and reload .bashrc:

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

2. Reopen the terminal so .bashrc settings are refreshed. At this point pyenv seems to be available and env shows (which I believe is correct):

PYENV_ROOT=/home/lucas/.pyenv
PATH=/home/lucas/.pyenv/plugins/pyenv-virtualenv/shims:/home/lucas/.pyenv/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/sbin:/usr/sbin:/sbin

3. Install Python 3.9.0:

lucas@rockpro64:~$ pyenv install 3.9.0
Installing Python-3.9.0...
Installed Python-3.9.0 to /home/lucas/.pyenv/versions/3.9.0

4. Create new virtualenv for Python 3.9.0:

lucas@rockpro64:~$ pyenv virtualenv 3.9.0 sandbox
Looking in links: /tmp/tmpgq78tlhc
Requirement already satisfied: setuptools in /home/lucas/.pyenv/versions/3.9.0/envs/sandbox/lib/python3.9/site-packages (49.2.1)
Requirement already satisfied: pip in /home/lucas/.pyenv/versions/3.9.0/envs/sandbox/lib/python3.9/site-packages (20.2.3)

5. Run pyenv rehash (just in case)
6. Activate pyenv environment (the pyenv seems to be activated as the prompt changes displaying the environment name):

lucas@rockpro64:~$ pyenv activate sandbox 
pyenv-virtualenv: prompt changing will be removed from future release. configure `export PYENV_VIRTUALENV_DISABLE_PROMPT=1' to simulate the behavior.
(sandbox) lucas@rockpro64:~$

7. Run python (fails):

(sandbox) lucas@rockpro64:~$ python
bash: python: command not found
(sandbox) lucas@rockpro64:~$

Unfortunately I don't have another system to keep testing, but not long ago I did this on a fresh Debian installation without issues. I'm also running another machine with FreeBSD and though I've installed pyenv long ago (and is working perfectly) I checked the PATH env variables and are both the same.

Something that I found interesting is that pyenv which python reports:

(sandbox) lucas@rockpro64:~$ pyenv which python
/home/lucas/.pyenv/versions/sandbox/bin/python

And if I run: /home/lucas/.pyenv/versions/sandbox/bin/python of course this works:

Python 3.9.0 (default, Nov 27 2021, 16:31:51) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

I can't see if I've missed something or there's something extra that needs to be done on Armbian. I've looked for information regarding this issue but couldn't find someone having the same or a similar problem.

It looks as if the /home/lucas/.pyenv/versions/sandbox/bin/ path is not exposed to the shell after the environment has been activated (if this is indeed the issue).

Thanks for your time,
Lucas.

[quanticle]

I think I'm running into the same issue on MacOS. I have MacOS 11.6, with zsh. I just did a fresh install of pyenv by running:

curl https://pyenv.run | bash

per the instructions in pyenv-installer, and set up my environment by adding the following to my $HOME/.zshrc:

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

Although a simple restart of the shell ought to have been sufficient, I rebooted, just to be absolutely sure.

I then installed Python 3.6 with the following command:

CFLAGS="-I$(brew --prefix openssl)/include -I$(brew --prefix bzip2)/include -I$(brew --prefix readline)/include -I$(xcrun --show-sdk-path)/usr/include" LDFLAGS="-L$(brew --prefix openssl)/lib -L$(brew --prefix readline)/lib -L$(brew --prefix zlib)/lib -L$(brew --prefix bzip2)/lib" pyenv install --patch 3.6.15 < <(curl -sSL https://github.com/python/cpython/commit/8ea6353.patch\?full_index\=1)

per this bug. The installation proceeded and completed successfully.

I then ran pyenv global 3.6.15 to set the global python version to 3.6.15, and indeed pyenv versions shows that to be the case:

  system
* 3.6.15 (set by /Users/<redacted>/.python-version)

However, when I run python --version, I get:

Python 2.7.16

which is the ancient version of Python currently shipping with MacOS.

I can see a directory for 3.6.15 in $HOME/.pyenv/versions, so clearly it has been installed. It's just that it's not being added to the $PATH correctly.