Tracking Issue for `update --precise` with pre-release

ehuss commented 8 months ago

Summary

RFC: #3493 Original issue: #12579 Implementation: https://github.com/rust-lang/cargo/pull/13626 Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#precise-pre-release

Extends cargo update --precise to allow pre-release versions, even if the dependency declarations do not specify a pre-release.

Unresolved Issues

[ ] Upstream pre-release match logic to semver crate
[ ] Upper bound semantic. See the unresolved questions in the RFC.

Future Extensions

No response

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

linyihai commented 7 months ago

Since https://github.com/rust-lang/cargo/pull/13296 had merged, i think i can lend a hand to continue.

Just in case I forgot, I was gonna @rustbot claim.

epage commented 7 months ago

I believe @eopb was planning on working on this. I'd recommend coordinating with them

eopb commented 7 months ago

Thanks Ed. Yes, I'm still intending to work on this. If you'd like to help @linyihai, please reach out to me on zulip (under the same username as here).

I'm sure we can work together. The last thing I'd want to do is to slow things down by trying to hog this tracking issue.

linyihai commented 7 months ago

Yes, I'm still intending to work on this. I'm sure we can work together. The last thing I'd want to do is to slow things down by trying to hog this tracking issue.

I'm sorry that I started the claim without further understanding of the requirement. You're the one who came up with this RFC, so I'm sure you know more details than I do. If you think it's better to do it yourself, that's fine. If you need help, break it down into smaller issues so that others see it and can help @eopb

please reach out to me on zulip (under the same username as here).

I'll be in touch if I need anything. Thank you @eopb

linyihai commented 6 months ago

FYI，I recently tried to implement an MVP based on RFC content.

weihanglo commented 4 months ago

https://github.com/rust-lang/cargo/pull/14013 shows the current implementation is a bit buggy, and there are upper bound semantic issues not yet resolved. See these test cases:

https://github.com/rust-lang/cargo/blob/050f88c3316178a064619b79ef9f56f0583488cc/src/cargo/util/semver_ext.rs#L204-L233

It is technically possible to fix them inside cargo. However to do that we'll need to duplicate the logic in semver crate. I am in the team of upstreaming things to semver.

linyihai commented 4 months ago

Yes, The semver crate only supports to compare prerelease with prerelease if I remember correct， https://docs.rs/semver/latest/src/semver/eval.rs.html#14-21

 // If a version has a prerelease tag (for example, 1.2.3-alpha.3) then it
    // will only be allowed to satisfy req if at least one comparator with the
    // same major.minor.patch also has a prerelease tag.
    for cmp in &req.comparators {
        if pre_is_compatible(cmp, ver) {
            return true;
        }
    }

So we need to add the pre tag to the version_req in order to use the semver crate, like RFC writes:

So before,

1.2.3  -> ^1.2.3 -> >=1.2.3, <2.0.0 (with implicit holes excluding pre-release versions)
would become

1.2.3  -> ^1.2.3 -> >=1.2.3, <2.0.0-0

linyihai commented 3 months ago

I have drafted a semver side PR to address upper bound semantic, but it stucks on node tests.

Also, my changes to cargo can be viewed in detail in this branch, which seems to solve the problem

linyihai commented 2 months ago

After some experiments on semver PR, I found something interesting,

the semver crate matches implementaion may be based on node semver compatibility. the semver matches follow the limit if the version has a prerelease tag then its MAJOR.MINOR.PATCH must be same with the VersionReq at least once, and another issuse is it can't handle partial VersionReq
By removing the limit and handle the partial VersionReq, the first proposed semantic came out. The prerelease tag padding logic has some controversial, like '<4.2', we chose pading it to '<4.2.0' not '<4.2.0-0' .

By look into the node semver compatibility semantic, it offers includePrerelease=true to remove the limit, then I add the test and try to implement it in semver, see https://github.com/dtolnay/semver/pull/321#issuecomment-2249961396. The result is the node semver compatibility implement ation also covers the semantic proposed by https://github.com/rust-lang/rfcs/pull/3493.

rust-lang / cargo