Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python: identify uv environments #6510

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

python: identify uv environments #6510

wants to merge 4 commits into from

Conversation

austin3dickey
Copy link
Contributor

@austin3dickey austin3dickey commented Feb 27, 2025

Addresses #6476.

image

Release Notes

New Features

Bug Fixes

  • N/A

QA Notes

I'd recommend clearing Positron state before testing this, since there's a lot of environment caching.

Set up uv on your system: https://docs.astral.sh/uv/getting-started/installation/

Try creating a venv or two and see how they look in the picker.

@:interpreter @:extensions

Copy link

github-actions bot commented Feb 27, 2025

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:interpreter @:extensions

readme  valid tags

@austin3dickey austin3dickey force-pushed the aus/uvlocator branch 5 times, most recently from 1c790f0 to 6e8bd14 Compare February 27, 2025 17:08
@austin3dickey
Copy link
Contributor Author

This is coming along pretty well, but I'm not sure it's classifying all uv-managed pythons on my system as uv. In particular I've used some of these shenanigans in the past and it still thinks those are global.

I probably want to polish up all these cases and make sure we have tests for them.

@austin3dickey austin3dickey force-pushed the aus/uvlocator branch 2 times, most recently from 0751519 to b0566c5 Compare March 3, 2025 20:15
@@ -253,6 +253,7 @@ function createWorkspaceLocator(ext: ExtensionState): WorkspaceLocators {
new HatchLocator(root.fsPath),
new PixiLocator(root.fsPath),
new CustomWorkspaceLocator(root.fsPath),
// TODO: uv?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still wrestling with whether I need to make a UvLocator and if so, what its scope should be. Right now everything seems to work even without one. I think this is because of the changes I made to the 3 files in pythonEnvironments/base/locators/lowLevel/. But that may not be the cleanest solution, and also it might be missing some? (still need to test)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I'm not quite sure how this interacts with PET?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure about this one, let's see what Isabel says.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say it is not needed, since uv envs are the same as venvs, which are already discovered. The one thing we might want to think about is if uv puts envs in nonstandard locations; ~/.local/ is one example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@isabelizimm saw an issue earlier where it wasn't finding e.g. ~/.local/bin/python if you used uv python install --preview to install that. This doesn't happen to me, and I think it's because ~/.local/bin is on my PATH. When I tried clearing Positron state and removing it from my PATH, that happened to me too. (Though interestingly it still found ~/.local/bin/python3.12, so that must have been picked up by something else, like a symlink from a venv or something.)

Question: is this okay behavior? Or should we always try to look in ~/.local/bin regardless of PATH?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be okay to always look in ~/.local/, since it is a known location for uv envs

// --- Start Positron ---
if (native.executable && (await isUvEnvironment(native.executable))) {
traceInfo(`Found uv environment: ${native.executable}`);
native.kind = NativePythonEnvironmentKind.Uv;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since PET recognizes uv envs as venvs, here's where we patch them. Related: microsoft/python-environment-tools#152 (comment)

@austin3dickey austin3dickey changed the title WIP: python: identify uv environments python: identify uv environments Mar 6, 2025
@austin3dickey austin3dickey marked this pull request as ready for review March 6, 2025 18:29
@austin3dickey
Copy link
Contributor Author

Okay I think this PR is good to go! I've been messing around locally and I think most of the issues have been worked out.

@jthomasmock
Copy link
Contributor

Minor nit/opinion, but what do we think about:

  • (uv: .venv) -- suggestion
  • (.venv: uv) -- current
  • (uv venv) -- alternative that matches the CLI command?

I think that might help with visual search or comparison, and in this aspect I think the fact that it's a uv-managed environment is more important than it's a .venv.

@austin3dickey
Copy link
Contributor Author

austin3dickey commented Mar 6, 2025

I think it's currently named this way because:

  • the default naming scheme for the Recommended and Workspace categories is 'folder_name': manager_name
  • the default naming scheme for the other categories is 'folder_name' (because the manager name is the category name)

But I agree that for uv that's not super helpful. Especially since a lot of the time the folder name is the default .venv. I can mess around and see if it's easy to change.

Maybe I could use the parent folder name instead.

@jthomasmock
Copy link
Contributor

I think it's currently named this way because:

  • the default naming scheme for the Recommended and Workspace categories is 'folder_name': manager_name
  • the default naming scheme for the other categories is 'folder_name' (because the manager name is the category name)

But I agree that for uv that's not super helpful. Especially since a lot of the time the folder name is the default .venv. I can mess around and see if it's easy to change.

Maybe I could use the parent folder name instead.

I do think that if it's following the recommendations or common approach then that's fine, and we can open that up as a future decision (whether to orient it a bit differently across the board depending on manager)

Copy link
Contributor

@seeM seeM left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to work for me with uv 0.6.5 and Python 3.11.9:

Screen.Recording.2025-03-07.at.14.19.07.mov

@austin3dickey
Copy link
Contributor Author

This doesn't seem to work for me with uv 0.6.5 and Python 3.11.9

Oh, this is wild. I notice in your video:

Using CPython 3.11.9 interpreter at: /Users/seem/.pyenv/versions/3.11.9/bin/python`

I didn't realize uv would choose interpreters not managed by uv! I probably knew this at one point (it's documented) but forgot.

I think I'll have to put back in the logic that checks whether there's a pyenv.cfg file in the venv with a uv key.

@austin3dickey
Copy link
Contributor Author

Cool @seeM that should be fixed. Tested locally.

@austin3dickey
Copy link
Contributor Author

Forgot to mention: if you're testing this locally it's probably good to clear Positron state first.

Copy link
Contributor

@isabelizimm isabelizimm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am seeing something a bit curious with the native locator. After refreshing interpreters, some of my ~/.local uv interpreters are under Global, not Uv, in the Select Interpreter dropdown.

Screenshot 2025-03-07 at 2 13 28 PM

However, once I choose one, start it up, and go back to Select Interpreter, it will appear under Uv.

Screenshot 2025-03-07 at 2 13 55 PM

I personally think this is small enough that it is non-blocking (I can't always repro), just log it and follow up on maybe?

Copy link
Contributor

@isabelizimm isabelizimm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm after it's decided if we auto-find ~/.local or not! this will be so exciting to have land 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants