Uv sync with --prerelease fails unexpectedly

[dariocurr]

I’m working with the following setup:
1. library A: currently in development with version 0.2.0.dev2
2. library B: expands the functionality of library A and depends explicitly on A==0.2.0.dev2. Library B has version 0.1.0.dev1
3. application: relies on library B and specifies the dependency B==0.1.0.dev1

When running uv sync, all --prerelease options (if-necessary, explicit, if-necessary-or-explicit) fail unless the allow one.
The issue arises because there’s a pre-release version in a third-party library dependency.

Since library B explicitly specifies A==0.2.0.dev2, I would expect the explicit option to handle this scenario.
My intent is to avoid globally allowing pre-release versions (allow) across all dependencies and instead restrict it to cases where they are explicitly required, even if these are third-party libraries.

This behaviour works as expected with pip, where such explicit versioning doesn’t cause any issues.

uv version: 0.5.4

[charliermarsh]

I believe this is working as intended. A==0.2.0.dev2 enables pre-releases for A, but not for whatever the transitive dependency is. I think you'd want to either use allow, or add the transitive dependency as a first-party dependency with a pre-release marker.

[dariocurr]

Using allow would mean enabling pre-release versions for all dependencies, which introduces unintended side effects and it's very dangerous.
For instance, if library A has a dependency like X>=1.1,<1.2, this approach could select 1.1.5.dev5 instead of the latest stable version 1.1.4 for X.
These all-or-nothing options of pre-releases are not viable solutions in our scenario.

I strongly believe the if-necessary option should address this use case (as pip does)

Alternatively, uv could consider adding a new option, such as if-necessary-with-third-party, to explicitly handle situations where third-party dependencies have explicit pre-release requirements (==) specified in the dependency chain. If I explicitly specified it, I am explicitly accepting it

Such an enhancement would ensure that explicit versioning requirements are respected without globally relaxing constraints for all dependencies

[notatallshaw]

I do think the uv option is badly named, to better describe what it does it should be something like if-only-prereleases.

[dariocurr]

Any updates on this? This is critical for us to ship uv in our pipelines

[zanieb]

Why can't you add the pre-release dependency as a first-party requirement to explicitly opt-in?

[dariocurr]

Why can't you add the pre-release dependency as a first-party requirement to explicitly opt-in?

Because that's not the way it should be, and I don't want to force my team to do something that shouldn't be done.
Again, this is the way pip works. This is the way cargo works. I only encountered this behavior when working with uv

[zanieb]

Sorry, but "shouldn't be done" is subjective and pip is not a standard. Our motivation and stance this is explained in detail at https://docs.astral.sh/uv/pip/compatibility/#pre-release-compatibility

[notatallshaw]

Well, I will point out that uv isn't following the standards here, which do state a prerelease should be selected when there is no other option. But this discrepancy is documented in the compatibility guide, and the standards are only well defined for a single specifier, not a resolution.

Also pip doesn't follow the standard here fully either, as it inherits this behavior from packaging and I've found packaging hasn't consistently implemented this: pypa/packaging#856

P.s. let's not get into a discussion on standards here, they're not very clearly laid out or worded, so it can be easy to jump to wrong conclusions for them and this isn't the right forum. If you're interested in the latest thinking on pre-releaees in the standards see: https://discuss.python.org/t/proposal-intersect-and-disjoint-operations-for-python-version-specifiers/71888

I'm hoping we get a new PEP proposal on this soon where we can have a productive discussion on this.