search

pubgrub-rs / advanced_dependency_providers

experiment with the DependencyProvider trait
1 stars 0 forks source link

"pre-release" #3

Open Eh2406 opened 4 years ago

Eh2406 commented 4 years ago

"pre-release" (in cargo) is part of the semver spec that allows versions like 1.0.0-alpha. I don't know how dart supports this but I believe it does.

This issue is to split off and continue the conversation from https://github.com/pubgrub-rs/pubgrub/issues/39

Eh2406 commented 4 years ago

To summarize the comments from https://github.com/pubgrub-rs/pubgrub/issues/39 so far:

mpizenberg: https://github.com/pubgrub-rs/pubgrub/issues/39#issuecomment-710786729

Pre-release

Pre-releases are versions. So the main question here is if the Version trait can express the kind of behavior that pre-releases are supposed to follow. Under which conditions are pre-releases selectable by Cargo? What kind of constraints enable them being picked in Cargo.toml? is it only for direct dependencies, or can they also being picked for indirect dependencies? How does that play with the patches?

aleksator: https://github.com/pubgrub-rs/pubgrub/issues/39#issuecomment-710797433

Pre-release

Interestingly handling of pre-release versions still seems to be an open question for cargo: https://github.com/rust-lang/cargo/issues/2222.

Currently they do the following (correct me if I'm wrong):

Under which conditions are pre-releases selectable by Cargo?

Only if specifically requested I believe.

is it only for direct dependencies, or can they also being picked for indirect dependencies?

Only for those packages that requested the prerelease.

Also from https://github.com/pubgrub-rs/pubgrub/issues/49:

seems like something that will prevent usage of things like pre-releases or versions based on dates, floating point numbers or other potentially valid versions otherwise.

For example: a. Range([1.0.0, Some(1.1.0-beta)]) meaning something like normal versions between 1.0.0 and 1.1.0 and pre-releases of 1.1.0 b. Range([1.1.0-alpha, Some(1.2.0)])meaning something like normal versions between 1.1.0 and 1.2.0 and pre-releases of 1.1.0

So a.union(b) will give Range([1.0.0, Some(1.2.0)]) as 1.1.0-alpha < 1.1.0-beta so we can merge the intervals. Meaning something like normal versions between 1.0.0 and 1.2.0. But v=1.1.0-beta and v=1.1.0-alpha both are accepted by both a and b but not a.union(b), witch seams not great.

Given that kind of tricky corner case I am not seeing a way to support pre-releases without some way to redefine Range.

Eh2406 commented 4 years ago

One thing that makes this complicated is that different package managers handle "pre-release" differently. From the example above I think it will be hard to be sure that a Version trait based solution always gets the correct answer, for any given definition of "correct answer".