Don't enable pre-releases when `!=` is used with pre-release specifier
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
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)
Thanks, we'll take a look!
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.
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.)
So, I think the problem is that
zarr!=3.0.0a0is causing uv to think that pre-releases are acceptable forzarr, so it's then picking the newest version ofzarr, which is3.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?
Does --prereleases disallow work? The default is if-necessary-or-explicit and these are "explicit" specifiers.
https://docs.astral.sh/uv/reference/settings/#prerelease
Yeah I think --prerelease disallow (or UV_PRERELEASE, or in your pyproject.toml) would be the recommended solution.
So, I think the problem is that
zarr!=3.0.0a0is causing uv to think that pre-releases are acceptable forzarr, so it's then picking the newest version ofzarr, which is3.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
Interesting, ok, we could change that. What do you think @zanieb? Seems reasonable to me.
I think that's reasonable too, but low priority to change.
Retitled the issue and added help-wanted.