Fails to load pyenv virtualenv's

[justinerickson]

Repro steps:

1. Setup pyenv virtualenv as your local .python-version for your project
2. VS Code automatically installs Python Environments extension automatically as part of Python/Python Debugger auto update

Expected: VS Code continues to select the correct pyenv virtualenv per .python-version as before
Actual: VS Code fails to load the pyenv virtualenv

3. Use Command Palette to go to Python: Select interpreter

Expected: My pyenv virtualenv is listed
Actual: pyenv virtualenv are missing from the environments list

Workaround:
4. Uninstall Python Environments extension and restart extension

Everything works as expected:

• VS Code correctly selects pyenv virtualenv per .python-version as before
• Python: Select interpreter correctly lists my pyenv virtualenv

Note:

• This was quite frustrating to have this was automatically installed without notice. Especially since this is marked as Preview software so not ready for rollout. This took longer to debug/uninstall because I didn't know something was installed without my notice and I wasted time trying to rollback the wrong extensions.

[karthiknadig]

Please try the pre-release version published recently. We addressed a bug where pyenv-virtual env was not visible in the list.

[justinerickson]

The pre-release seems to work (though I need to manually re-select my environment again from VS Code)

[eleanorjboyd]

Hi @justinerickson! Thanks for trying to pre-release to verify it works as a fix. We currently do not support .python-version but I am going to work now on adding it.

The plan for .python-version will be as follows, feel free to provide feedback as a user for what you would want to see, thanks!

• on activation of the python environments extension, if there is not already an environment selected (as will occur after a user selects an environment on a different time working on the same workspace for example) then we will look at the .python-version and attempt to find a compatible version on the users machine
• when a user selects an interpreter in a given workspace where there exists a .python-version file at the root, we will trigger pyenv equivalent on that directory.

stretch goals which might not be a 1st priority:

• watch for edits to .python-version and update the selected interpreter as a result

[justinerickson]

Thanks. That sounds good to me. One question and one suggestion:

• Question: Would the PyEnv label in the "Select a Python Environment" be updated to indicate which one matches the .python-version?

• Suggestion: For projects built as monorepos (like mine) the .python-version will be in the appropriate subdirectories. For example I have backend/.python-version as the frontend is written in React so not Python-based. This would require traversing directories and dealing with potential for multiple .python-versions in different subdirectories.

Btw I saw you pushed the 1.2.0 today and I just updated/confirmed it works as expected

[justinerickson]

It seems that without this extension monorepos work and this extension has other bugs (like #667 I just filed with using uv).

I'd highly recommend disabling / not installing this by default in VS Code Python setups as this is not ready and causing surprising regressions in very commonly used Python setups (pyenv virtualenv and uv) that work just fine without this extension.

[eleanorjboyd]

Thanks. That sounds good to me. One question and one suggestion:

• Question: Would the PyEnv label in the "Select a Python Environment" be updated to indicate which one matches the .python-version?
• Suggestion: For projects built as monorepos (like mine) the .python-version will be in the appropriate subdirectories. For example I have backend/.python-version as the frontend is written in React so not Python-based. This would require traversing directories and dealing with potential for multiple .python-versions in different subdirectories.

Btw I saw you pushed the 1.2.0 today and I just updated/confirmed it works as expected

The label update is question is a great idea- I didn't consider this before but we can add it in.

additionally we can traverse the workspace to look for multiple, that should probably be included in the MVP

[eleanorjboyd]

It seems that without this extension monorepos work and this extension has other bugs (like #667 I just filed with using uv).

I'd highly recommend disabling / not installing this by default in VS Code Python setups as this is not ready and causing surprising regressions in very commonly used Python setups (pyenv virtualenv and uv) that work just fine without this extension.

Thank you for filing the other issue! We have been testing this extension for over 6 months and tried to be thurough but there are obviously items that slipped through the cracks. I will work diligently to get these updates to reach feature parity with the old experience before introducing to more users (currently only 20% of users on stable get this experience)

[justinerickson]

FWIW, I think these bugs are still in the very simple cases, so I don't think this extension is close to being ready for the complexities and varieties of Python environments to come. This is not intended to be criticism of the team's capabilities or efforts to date but more a recognition of the complexity of the problem. As evidenced by the number of different Python environment and package managers (eg uv, pyenv, poetry, conda, rye, pip, etc), this is a tricky, dynamic, and yet unsolved problem space.

I also just read through what this extension is expected to do. While I can see this extension as helpful for more novice Python developers unfamiliar with Python environments/packages, I don't think this extension adds much value for more experienced/advanced developers who I'd expect (like me) want to manage their environments in git declaratively (eg via pyproject.toml, environment.yml, requirements.txt, etc) and not through a GUI. By volume there might be more novice Python developers and it's likely harder for them to get started without a simple environment manager, but silently installing it for all developers doesn't seem like the right trade-off as it:

• violates principle of least surprise
• takes away from one VS Code's most popular strengths of being lightweight IDE that doesn't try to do too much

Additionally, with more developers using LLMs for coding assistance, even novice users may increasingly indirectly prefer declarative configurations that LLMs can easily read and modify as text files.

A few thoughts to consider:

• Instead of having this automatically and quietly install for all Python extension users, have it a separate extension pop-up so that it's clear a new extension is requesting to install (maybe even only show this when there isn't already a non-default environment manager present)
• Keep uninstalled by default, and put into getting started guide and VS Code's Python walkthrough (and other locations that make it obvious/easy for novice developers without breaking the mainstream/advanced users)
• Keep uninstalled by default, and put option in the base "Python: Select Interpreter" to request to install this extension

Thanks for considering these thoughts. I won't press this further here as I know this is off-topic from the specific bug. Let me know if you think this feedback would be helpful to post in a different forum and/or it'd be helpful to explore any thoughts above.