update labeling when uv is used

[eleanorjboyd]

When the extension detects that uv is installed and is being used for venv actions (such as creating a venv or installing packages), update the venv label in the VS Code sidebar to display venv [uv]. This will help users easily see that uv is being used for their environment management. The detection should be based on whether uv is found and used, and the label update should be visible in the sidebar UI. Verbose logs can be used to confirm the actual command execution, but the main user-facing change is the sidebar label update.

[eleanorjboyd]

the desired experience would be to see this

[Carbaz]

What if some environments are based on UV and some others are based on plain python -m venv ?

I think it would be much better to add the [UV] tag only to those environments.

You can check if a ´.venv´ has been created with UV by reading its pyvenv.cfg file, if it is an UV one there will be an "uv" entry:
(I redacted several personal paths but the structure is from two actual different .venv folders I have)

With UV: pyvenv.cfg Note the third entry

home = **** python interpreter path goes here ****
implementation = CPython
uv = 0.8.14
version_info = 3.12.11
include-system-site-packages = false
prompt = *** environment name for prompt ***

Without UV: pyvenv.cfg

home = **** python interpreter path goes here ****
include-system-site-packages = false
version = 3.13.5
executable = **** python interpreter path goes here ****
command = ***** command used to create the virtual env *****

[Carbaz]

Sorry for piling on, just wanted to clarify what might be a core misconception.

UV isn’t simply a replacement for venv, it’s actually more comparable to tools like Pipenv or Poetry. Its strength lies in being a robust dependency and package manager, which is precisely why it’s gaining traction among Python developers.

Given that seems possible to detect whether a .venv is UV-based or not, I believe UV deserves its own dedicated section, just like Poetry and Pipenv.

That way, users who want to create a bare virtual environment can refer to the venv section, while those opting for UV can go directly to the UV section. Same goes for listing environments: keeping them clearly separated improves clarity and usability.

It’s quite common to work in multi-repo or multi-service setups where different services rely on different dependency managers.
In that context, virtual environment management is more of a convenience feature offered by these tools, not their core purpose, but a helpful one nonetheless.

[karthiknadig]

One thing to note that even if an env was not created with UV, it does handle package management for that environment. Some users want to use uv regardless of venv or uv created envs.

We will discuss this and see what works best. There is also an extension in the works from the community for full `uv‘ support that includes some bits beyond the scope of this extension. So, what we provide might be interim until that becomes available.

[schlich]

I want to add here what I mentioned in the above linked issue in the uv repo... which is that right now my primary pain point with the way things are currently set up in VS Code is that it's not configured such that Agents/MCP add packages correctly, i have to implement some bespoke solutions there and it would be nice if VS Code had a reliable entry point so i dont have to yell at my models to use uv add over and over again

[eleanorjboyd]

@schlich this is definitely a pain point we want to fix. Are you using copilot or a different agent/mcp integration? We have some tools that should be called for environment creation and package management which hook directly into the python environments extension which chat should defer too. Curious if you are seeing it calls those and it is doing it wrong or if its not calling them at all (or I guess you may not be using this integration)

[schlich]

I am using Copilot, and it does hook into the python environments extension but in addition to the "manually edit pyproject.toml" -> "run pip install" flow being naturally more flaky than a single uv add command, it won't update my uv.lock file which is important for project health. Thus, I have to resort to custom prompts/custom mcp and lose out on the benefits of Python Environments which i unfortunately am currently having to disable because of the poor experience.

[schlich]

I've also tried this custom mcp server (3 stars so who knows if it's credible) but Copilot hasn't taken to it, preferring other methods/tool calls