Repository navigation
update labeling when uv is used #809
Description
Activity
the desired experience would be to see this
Reacted by Carlos BazagaWhat 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.cfgfile, 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.venvfolders I have)With UV:
pyvenv.cfgNote the third entryhome = **** 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.cfghome = **** 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 *****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
.venvis 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.Reacted by Brian and David HootonReacted by Ty Schlichenmeyer, matthias-busch and David HootonOne 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
uvregardless ofvenvoruvcreated 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.
Reacted by Carlos Bazaga, Eleanor Boyd, cyh and David HootonI 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 addover and over againTy Schlichenmeyer (@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)
I am using Copilot, and it does hook into the python environments extension but in addition to the "manually edit
pyproject.toml" -> "runpip install" flow being naturally more flaky than a singleuv addcommand, it won't update myuv.lockfile which is important for project health. Thus, I have to resort to custom prompts/custom mcp and lose out on the benefits ofPython Environmentswhich i unfortunately am currently having to disable because of the poor experience.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
Eleanor Boyd (@eleanorjboyd) can you clarify what is even meant here when you say that "uv is being used for environment management"? Does it use the
uv pipinterface? If it's supposed to use the full suite ofuvcli commands, it has not done that for me at allHi- yes it should use
uv pipwhen you have uv installed. Please check the logs and copy and paste them here if that is not the case (and maybe also the output fromuv --helpto confirm it is accessible in your workspace / terminal)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!
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!
Hi, I saw this auto-closing again but as you previously reopened it and left it as
info-neededI'm sharing this as a feedback on the current behavior:I created another issue for a problem when several components have venvs here: #1032
Scenario there is having a workspace folder opened which contains subfolders each of them is one component with their own virtual environments, and each one with different managers, on the given casePipenv,uvand barevenv, which can be a common scenario on multi services projects, for example.There you can, on the second step, see this:
- On
picturescomponent I used rawpython -m venv .venv - On
agentscomponent I useduv
So
venvscreated/used withuvhave the tag and those not doesn't.Problem on the new issue is it's not consistent on showing more than one
venvwhen they are present, as soon as it updates only the currently chosen one is shown.Take a look at the issue as it may be related to this one, but when it works, on what it takes to this issue, it seems to properly tag with
uvwhen required.- On
- locked as resolved and limited conversation to collaborators
on Apr 29, 2026
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.