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

[Czaki]

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)

[charliermarsh]

Thanks, we'll take a look!

[charliermarsh]

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]

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]

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]

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]

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

[notatallshaw]

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: pypa/packaging#794

[charliermarsh]

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

[zanieb]

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

[charliermarsh]

Retitled the issue and added help-wanted.