feat: support for uv-installed pythons

[saucoide]

A question more than a PR, now that uv supports bringing its own pythons, i wanted to try simplify a CI and not have to install python from other sources, but nox is currently now able to find uv-installed pythons (someone else's issue @UV about this same thing astral-sh/uv#6579 )

would it make sense to add a more fleshed out version of this? meaning passing the desired interpreter to uv venv -p {interpreter}, or should this be done by other mechanism that adds uv's python interpreters to $PATH ?

note: this is just a draft to show an example, kind of works but also breaks tests and probably breaks uv|virtualenv and other things

[henryiii]

I think it makes sense, especially if it's roughly this easy. :)

[saucoide]

@henryiii i've updated this a bit, but there is a failing test locally test__resolved_interpreter_windows_path_and_version_fails which i dont quite understand though :/

[saucoide]

im not happy about ignoring the uv-python cases for those windows tests, but i am not familiar with how nox works on windows to touch that part, so if anyone has any ideas it'll be helpful

[nugend]

@saucoide Just want to express my appreciation for this PR. This has already made my life way easier!

[saucoide]

thanks but tbh i wouldn't use it just yet 😅 there is still something wrong with it, the tox-to-nox tests fails mixing up the interpreter depending on which order the tests are run, so there is something broken still

[saucoide]

ok so this may be an issue with uv (or with how i thought it would behave) looks like if you run

uv python install pypy3.8 (there is a test that does it)

and then later on

uv venv -p python3.8 .venv

uv will go ahead and use the existing pypy to make the venv, will try to figure out if this is intended from uv's side or not

[henryiii]

I wonder if we could make pythonX -> cpythonX for uv? Just a thought.

[saucoide]

I wonder if we could make pythonX -> cpythonX for uv? Just a thought.

yes I think we might have to, originally i thought passing it as-is to uv would be nice, because you can then specify the python with uv's own version syntax, and whatever versions they support e.g. 3.13t, without having to do any translation. But it looks like it it might not work out, depending on what they do here astral-sh/uv#7118

ill try to test tomorrow with replacing python/cpython

[saucoide]

looks the uv people were faster so it works without changes now, this latest version seems ok

[saucoide]

@henryiii could you review and let me know if you think this approach is ok?

[henryiii]

I think this is great, my only question is if we should have some control for this. We could in theory add downloading to the other backends (similar to how PDM and Hatch download Pythons - and it comes from the same place as uv's), so maybe we should have --download-python=auto,always,never? Not necessary for this PR unless the default wasn't auto.

[saucoide]

do you mean nox doing the downloading itself, or checking if hatch/pdm/uv are in path and use whatever is available to get the version requested?

[henryiii]

I believe PDM’s downloader is a standalone Python library we could use. But yes, nox downloading it itself.

[saucoide]

yeah that sounds useful, what would be the behaviors of auto? I'd interpret it like

• auto: prefer a present compatible version + download only if missing
• always: always use the standalone python, even if a compatible version is already present from another source?
• never: only if already preset

i can try to experiment a bit next week and see if i get something working (this week's a bit busy for me)

[henryiii]

Yes, that's exactly what I was thinking. The current behavior is "auto" for uv, and "never" for the other backends. (Actually, not sure about conda, that might be "always").

[layday]

This caught me completely by surprise in CI when I pre-installed Python with uv, only to have nox install and run my tests under a different version because I omitted the "t" suffix and even though I'd passed --error-on-missing-interpreters: https://github.com/layday/instawow/actions/runs/11359937505/job/31596873371#logs. I believe this should respect the --error-on-missing-interpreters flag.

[saucoide]

@layday
:/ yeah it doesn't fail because there is an interpreter, the one it downloaded, i haven't had time to add the options henryii mentioned to have a download=never in nox, meanwhile i think it should be possible to disable it for uv directly setting UV_PYTHON_DOWNLOADS=never

[layday]

meanwhile i think it should be possible to disable it for uv directly setting UV_PYTHON_DOWNLOADS=never

Thanks for the hint.

[henryiii]

Another issue I've noticed: this will install some uv pythons. Then subsequent uses of uv like uv run will suddenly start using an older Python instead of 3.13 because it installed some older missing version and it prefers its own Pythons. Not sure if there's a way to keep this from affecting uv usage.

uv run thing # Uses 3.13
nox ... # installs missing 3.12
uv run thing # Now uses 3.12

Simi-related, we should also make sure we fully support 3.13t as an identifier.