PYENV_VERSION incorrectly set in subshells

[laur89]

Prerequisite

• Make sure your problem is not listed in the common build problems.
• Make sure no duplicated issue has already been reported in the pyenv issues. You should look for closed issues, too.
• 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.
• Make sure your problem is not derived from packaging (e.g. Homebrew).
  • Please refer to the package documentation for the installation issues, etc.
• 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 (e.g. Ubuntu Linux 16.04):
  debian testing, amd64
• pyenv version:
  2.3.21
• Python version:
  3.11.2
• C Compiler information (e.g. gcc 7.3):
  gcc (Debian 12.2.0-14) 12.2.0

---

This is bit of a corner case, but could lose many hours for other people.
When shell is started from another process (a python one in my case), then this new shell will have PYENV_VERSION hardcoded to system value, which will break version detection. This, among other possible problems, breaks pyenv-virtualenv automatic environment activation.

Please refer to reproduction program:

#!/usr/bin/env python3

import os
import sys
import shlex
import subprocess

IN_PLACE_FLAG = '-i'
TERM_CMD = 'xterm -e {} {}'.format(sys.argv[0], IN_PLACE_FLAG)

# replace python process (ie. this same script) with shell's:
def launch_inplace(shell):
    #os.environ.pop('PYENV_VERSION', None)
    os.execvp(shell, [shell])


if __name__ == '__main__':
    if len(sys.argv) == 2 and sys.argv[1] == IN_PLACE_FLAG:
        launch_inplace('/bin/bash')
    else:
        # launch terminal process running this very same script with IN_PLACE_FLAG passed to it:
        subprocess.Popen(shlex.split(TERM_CMD))

When executed, this script will

• launch a new terminal process (xterm by default. please amend TERM_CMD if you don't have it installed) calling the same script with a flag
• when this script is loaded in the new terminal, it will replace the python process with /bin/bash

This effectively leaves us with a fresh shell.
The problem is: PYENV_VERSION in this new shell will have a value of system pre-set. To work around it, you can either

1. uncomment the first line of launch_inplace(); or
2. run unset PYENV_VERSION from your .bashrc before invoking pyenv init

I can't figure out from pyenv code where solution might lie, as PYENV_VERSION is set in a few places.

[native-api]

Same issue as #1675

There, the users accepted a workaround (to detect the specific use case and unset PYENV_VERSION in .bashrc).

[laur89]

Thanks, I'll just continue using my workaround in that case.

[native-api]

If you think this should be changed, you could argue so in that issue.

As it's explained there, so far, it's unclear whether we should set PYENV_VERSION in processes run with pyenv exec or not.

[laur89]

Nah, think your comment

It ensures that any subprocess that runs another Python-based command would use one from the same Python installation, even if you change the current directory.

makes perfect sense and this feature likely keeps away another set of possibly-difficult-to-debug issues. Think sub-terminals launched in this sense is rather specific corner case.

However, would it be possible for us to detect that a (interactive) sub-shell is launched in this manner, and thus ignore PYENV_VERSION for that particular case. If not, or it'd be too hacky, it might be a good idea to document this. Perhaps a quick line in readme or pin the github issue you linked above?