Installing Python with pyenv and --enable-framework is not entirely supported (macOS specific)

Environment data

• VS Code version: 1.57.1
• Extension version (available under the Extensions sidebar): v2021.6.944021595
• OS and version: Mac Mojave 10.14.6
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.9.5
• Type of virtual environment used (N/A | venv | virtualenv | conda | …): Pyenv 2.0.2 creating a framework install of Python
• Relevant/affected Python packages and their versions: -
• Relevant/affected Python-related VS Code extensions and their versions: -
• Value of the python.languageServer setting: PyLance

Expected behaviour

Creating a new terminal python.createTerminal when the project Python interpreter is set to a pyenv environment should invoke e.g. pyenv shell 3.9.5 when the terminal is opened.

Actual behaviour

When your interpreter is set to a framework install of Python created by pyenv, creating a new terminal python.createTerminal invokes e.g. pyenv shell 3.9 (notice the missing .5) which doesn’t exist, and the pyenv command fails.

Steps to reproduce:

1. Create a framework install of Python PYTHON_CONFIGURE_OPTS="--enable-framework" pyenv install 3.9.5
2. Open any vscode Python project and set the interpreter path using the ‘Edit Interpreter Path / Browse your file system…’ which turns out to be ~.pyenv/versions/3.9.5/Library/Frameworks/Python.framework/Versions/3.9/bin/python
3. Invoke python.createTerminal

See the erroneous result:

pyenv shell 3.9
pyenv: version `3.9' not installed

Discussion

As most developers don’t do ‘framework’ installs of pyenv Pythons, this may be an edge case that hasn’t been catered for. A normal pyenv python interpreter path is e.g. ~/.pyenv/versions/3.9.5/bin/python which works OK with regards to invoking pyenv shell 3.9.5 when python.createTerminal is issued.

It is only when dealing with a framework install via pyenv that the issue arises. Framework installs are necessary when developing wxPython based software, and many other types of development.

The workaround is to manually type in the path ~/.pyenv/versions/3.9.5/bin/python in which case everything works OK. 🎉

The trouble is that this shorter, correct path is impossible to enter in by browsing via the Browse your file system... dialog box. As soon as you double click on the bin folder (which is a symbolic link - that’s the problem) you are navigated to ~.pyenv/versions/3.9.5/Library/Frameworks/Python.framework/Versions/3.9/bin and end up with the erroneous path

which works for invoking Python in your projects, but not for opening bash shells with python.createTerminal.

P.S. The reason why pyenv shell 3.9 is invoked instead of pyenv shell 3.9.5 is no doubt because of the presence of the 3.9 fragment in the erroneous path ~.pyenv/versions/3.9.5/Library/Frameworks/Python.framework/Versions/3.9/bin.

If this issue is dismissed as ‘user error’ for entering an incorrect interpreter path, I would argue

• it is an OK python path for invoking python files
• it is the path that 99% of users will browse to using the UI
• it is impossible to browse to the correct, shorter, path using the UI, at least on a Mac
• entering the correct, shorter, path to python by hand requires advanced knowledge of this ‘issue’, which most developers will not have
• The correct shorter path is (usually) not available from the dropdown offered to users viz. see next point

Unless it has been chosen before, the choice to choose the correct ~/.pyenv/versions/3.9.5/bin/python path from the dropdown list of interpreters is not there. That’s another problem - vscode should list all pyenv interpreters in the dropdown list instead of forcing users to navigate around the filesystem choosing potentially erroneous paths.

[karrtikr]

That’s another problem - vscode should list all pyenv interpreters in the dropdown list instead of forcing users to navigate around the filesystem choosing potentially erroneous paths.

This is a dup of https://github.com/microsoft/vscode-python/issues/16231. Once it is available there hopefully you don’t have to go through the route of browsing to select the correct interpreter. Feel free to upvote that issue to raise priority.

The browsing issue is due to VSCode as the dialog box it provides us always resolves symlink folders: https://github.com/microsoft/vscode/issues/169563.

Closing in favor of these issues 🙂

[yoda-vid]

I needed to follow a similar workaround to select a Pyenv framework install of a Python interpreter in a virtual environment generated by Venv. Selecting the Python symlink from the Venv directory changed the path to ~/.pyenv/versions/3.8.13/bin/python. Instead, manually typing /path/to/myvenv/bin/python avoided the path change and allowed VS Code to detect the interpreter and the environment’s packages.