search

astral-sh / uv

An extremely fast Python package and project manager, written in Rust.
https://docs.astral.sh/uv
Apache License 2.0
22.35k stars 652 forks source link

Don't enable pre-releases when `!=` is used with pre-release specifier #6640

Open Czaki opened 1 month ago

Czaki commented 1 month ago

In napari project, we use uv to provide constraints files in automatic jobs

https://github.com/napari/napari/blob/35a99366f2a8ef5bcdbd6e1f874f5ca2a7572582/.github/workflows/upgrade_test_constraints.yml

In the last run, the output contained bumping zarr to prerelease version

obraz

even if we specify only lower bound constraint without any prerelease version: https://github.com/napari/napari/blob/35a99366f2a8ef5bcdbd6e1f874f5ca2a7572582/pyproject.toml#L143

The whole command used for compilation is:

uv pip compile --python-version 3.12 --output-file napari_repo/resources/constraints/constraints_py3.12.txt napari_repo/pyproject.toml napari_repo/resources/constraints/version_denylist.txt --extra pyqt5 --extra pyqt6 --extra pyside2 --extra pyside6_experimental --extra testing --extra testing_extra --extra optional

Commit showing problem is here napari/napari@c81b0d0 (#7212) And problematic line here napari/napari@c81b0d0 (#7212)

charliermarsh commented 1 month ago

Thanks, we'll take a look!

charliermarsh commented 1 month ago

So, I think the problem is that zarr!=3.0.0a0 is causing uv to think that pre-releases are acceptable for zarr, so it's then picking the newest version of zarr, which is 3.0.0a1.

charliermarsh commented 1 month ago

If I remove that line from napari_repo/resources/constraints/version_denylist.txt, it works as expected... (Also make sure you remove resources/constraints/constraints_py3.12.txt if it exists, since if that contains a pre-release, we'll continue using that pinned version.)

Czaki commented 1 month ago

So, I think the problem is that zarr!=3.0.0a0 is causing uv to think that pre-releases are acceptable for zarr, so it's then picking the newest version of zarr, which is 3.0.0a1.

oh. We are using this file also in pre-release tests.

I there, any option to provide constraints, but without allowing to enable pre-release? to have a single source of problematic versions?

zanieb commented 1 month ago

Does --prereleases disallow work? The default is if-necessary-or-explicit and these are "explicit" specifiers.

https://docs.astral.sh/uv/reference/settings/#prerelease

charliermarsh commented 1 month ago

Yeah I think --prerelease disallow (or UV_PRERELEASE, or in your pyproject.toml) would be the recommended solution.

notatallshaw commented 1 month ago

So, I think the problem is that zarr!=3.0.0a0 is causing uv to think that pre-releases are acceptable for zarr, so it's then picking the newest version of zarr, which is 3.0.0a1.

FYI, the intent of the spec author is that != should never imply a pre-release.

I have a PR for packaging to match uv's behavior on < and >, which is part of the spec, but also explicitly test != to not imply a pre-release: https://github.com/pypa/packaging/pull/794

charliermarsh commented 1 month ago

Interesting, ok, we could change that. What do you think @zanieb? Seems reasonable to me.

zanieb commented 1 month ago

I think that's reasonable too, but low priority to change.

charliermarsh commented 1 month ago

Retitled the issue and added help-wanted.