Test pyenv environments are autoselected

[karrtikr]

Refs: #1167

• windows @joyceerhl
• linux @connor4312
• macOS @rzhao271

Complexity: 4

Create Issue

---

Requirements

• Python extension pre-release

Verification

• Install pyenv if not already, make sure to reopen shells after:
  • non-windows: https://github.com/pyenv/pyenv?tab=readme-ov-file#getting-pyenv
  • windows: https://github.com/pyenv-win/pyenv-win?tab=readme-ov-file#quick-start
• Run pyenv --version to check if the installation was successful.
• Run pyenv install -l to check a list of Python versions supported by pyenv
• Run pyenv install <version> to install a couple of supported versions
• Run pyenv global <version> to set a Python version as the global version, for eg. pyenv global 3.9.0
• Run pyenv which python and record the full path to python somewhere
• Create a new workspace folder with a Python file
• Run Python: Clear cache and reload window command
• Make sure the recorded python is the one which is selected:
  
• Run pyenv local <version> command to select another version of Python
• Run Python: Clear cache and reload window command, make sure the latest version set is now selected

[rzhao271]

This TPI didn't seem to work for me on macOS with zsh.
pyenv global: 3.6.15
pyenv local in the specific workspace folder: 3.11.8
Recommended interpreter after running code-insiders . inside the specific folder: pyenv 3.12.2

[connor4312]

This worked for me on Fedora, but I wonder if there should be an easier way for users to refresh their pyenv without having to clear cache and reload window. Maybe you can detect if a pyenv command was run in the terminal with shell integration as a starting point?

[karrtikr]

@connor4312 Pyenv environments are currently considered global environments, so we only automatically trigger discovery once for them. Maybe if we had a global watcher, or watch for all commands being run as you said, that could solve the issue. But we've noticed previously that it leads to a performance overhead and overall loss in experience.

Created #23139 which should make things better for now: we can look if we have a .python-version in the new workspace, to decide whether we should trigger pyenv discovery.

This issue should also be addressed with #22836 once Pyenv extension which manages its own environments.

[LoganB99]

@karrtikr @connor4312 does this issue have anything to do with launch.json not respecting my pipenv virtualenv? this used to work, but now i am getting errors that a module is not found if i run python through the debug console.. it is installed in my pipenv, but for some reason it is looking in my global pyenv for the module??

[LoganB99]

resolved, sorry