pyenv shim detection and smarter terminal activation for python.defaultInterpreterPath

[qrkourier]

Feature request summary

Please enhance the Python extension's handling of interpreter paths under .pyenv, specifically to correctly detect and treat the .pyenv/shims/python path without injecting pyenv shell <version> commands when interpreter selection is already delegated to pyenv.

Problem

When python.defaultInterpreterPath (or a selected interpreter path) is set to the pyenv shim (e.g., /home/user/.pyenv/shims/python), the extension currently treats it as a versioned environment and injects pyenv shell <name> in integrated terminals (see activation logic), which is unnecessary and always incorrect. The shim is designed to provide version selection via pyenv's own logic (pyenv local creates .python-version in project).

Desired behavior

• If the interpreter path is the .pyenv/shims/python shim, the extension should not inject any pyenv shell <name> command by default when activating terminals.
• Continue extracting <name> and injecting pyenv shell <name> only when the interpreter path is under .pyenv/versions/<name>/bin/python.
• Add regression tests to cover shim and versioned path cases.

Current behavior / code references

• pyenv activation provider injects pyenv shell <envName> if envType is Pyenv and envName is present
• resolver marks any interpreter path under .pyenv as a pyenv environment
• pyenv locator discovers environments by reading .pyenv/versions
• resolver extracts envName and kind from version path, used in above activation logic

Justification

• Users expect to use the shim as the default interpreter for portability, relying on pyenv's dynamic switching, and expect no forced activation injection.
• Over-injecting pyenv shell <name> disrupts the expected workflow and may unintentionally override local or global pyenv settings

Alternatives considered

• Manually switch global/local version via pyenv outside VS Code (works, but isn't user-friendly).
• Use versioned path everywhere (defeats one of the key reasons to use pyenv shims).
• Disable integrated terminal environment setup with python.terminal.activateEnvironment=false, which is global and prevents setting up project-specific interpreters for those that do not use the pyenv shim.

Additional context

Thank you for all your work on Python support! Smarter handling of pyenv shims makes the extension safer for Python users.

---

For maintainers: see in-code comments and links for logic details. This enhancement aims to protect portability while making strict interpreter enforcement possible when explicitly desired but not by default.

[eleanorjboyd]

Hi! Are you seeing this behavior with the python environments extension? We are moving to this extension for env management so if you haven't checked it out it would be great if you could take a look and update based on the new behavior. Since we have made updates to pyenv as a part of this new extension

[github-actions]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!