search

wntrblm / nox

Flexible test automation for Python
https://nox.thea.codes
Apache License 2.0
1.3k stars 149 forks source link

Support for uv.lock #841

Open hynek opened 3 weeks ago

hynek commented 3 weeks ago

How would this feature be useful?

uv added a cross-platform lock format in 0.3.0. I can see this to become a standard for packages to keep CI stable.

Given that uv sync doesn't have target-installations (yet), it's tricky

Describe the solution you'd like

I think it would be really cool if session.install(".[tests]") automatically discovered a uv.lock file and ran uv sync --extra tests but I could live with session.sync("extras") too.

Either would improve the overall Python DX tremendously.

Describe alternatives you've considered

Hand-craft it, I guess? One has to do manual change directories etc tho.

Anything else?

No response

jamesharris-garmin commented 2 weeks ago

Would https://github.com/astral-sh/uv/pull/6834 support this use case? It adds UV_PROJECT_ENVIRONMENT, I guess, once that lands, assuming nox provides a way to access the virtualenv path, you could implement a session that sets the uv environment to the specified nox location.

One thing to note about this is they expect to add a warning when VIRTUAL_ENV is set in a follow up PR: https://github.com/astral-sh/uv/pull/6864. But even this only warns if UV_PROJECT_ENVRIONMENT and VIRTUAL_ENV don't match. I'll be looking forward to that support happening.

hynek commented 1 week ago

JFTR UV_PROJECT_ENVIRONMENT has shipped.

jamesharris-garmin commented 1 week ago

seems like we could just make sure to export UV_PROJECT_ENVRIONMENT and set it equal to the virtualenv then you could call uv sync as a run_install call.

jamesharris-garmin commented 1 week ago

After experimenting with this it kind of breaks to do this via uv sync and this envrionment variable. uv sync destroys and recreates the environmetn every time if nox modifies it. so we can't just "reuse' the build environment. Maybe a better aproach would be to automatically generate a requirements file from the lock file and re-install it.

hynek commented 1 week ago

That seems a bit convoluted, it would make more sense to write up a proper bug report to Astral and ask them – they're usually quite receptive.

What exactly is nox doing there? Could it already be fixed using uv sync --inexact? Also, uv is so fast, venv reuse doesn't matter at all.

jamesharris-garmin commented 1 week ago

I haven't had a chance to dig too far into the behavior to see how this is supposed to work. I don't consider it a bug just yet. maybe nox is using a different python version than I expect?

edgarrmondragon commented 1 week ago

nox-poetry does that something similar for poetry.lock, so maybe what we need is an extension like that for uv?

cc @cjolowicz

henryiii commented 1 week ago

Tangent: We don't really support plugins here - ideally, you nox would be able to install it's own plugins, rather than assuming people can inject an extra plugin into wherever nox is installed. I'd like to eventually support these better.