Support for uv.lock

[hynek]

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]

Would astral-sh/uv#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: astral-sh/uv#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]

JFTR UV_PROJECT_ENVIRONMENT has shipped.

[jamesharris-garmin]

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]

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]

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]

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]

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

cc @cjolowicz

[henryiii]

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.

[Wurstnase]

I would like to contribute uv sync. Should I simple create a PR with my ideas, @henryiii?

[henryiii]

Could you describe your ideas first? You can start with a PR if that's easier. I was sort of waiting until the dependency groups and standardize lock file PEPs get resolution.

[Wurstnase]

Uh, I didn't realize that there is a new PEP¹ for lock files.
I just played around on my local project and this PR is what I've ended with: #857

I'm using the workspace feature from uv. So I need the --package option a lot.

Footnotes

1. PEP 751 ↩

[dariocurr]

Any news on this?

[Wurstnase]

My current prefered way is to use something like from the cookbook: https://nox.thea.codes/en/stable/cookbook.html#using-a-lockfile

[henryiii]

I think the environment feature will likely be pushed to the next release, but it still is the next major thing I want to work on.

Recipes like the cookbook one should be fine until then.