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

[ehuss]

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]

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]

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

[eopb]

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]

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]

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

[weihanglo]

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]

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]

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]

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.

[BatmanAoD]

Until this is implemented, is there any workaround to force Cargo to use a prerelease version of a crate that is required (using a non-prerelease string) by a dependency? I.e.:

foo
├── bar
│   └── tertiary v1.12.3
├── tertiary v1.13.0-dev.0
...

Here, is there any way to generate a valid Cargo.lock file without forking bar?

[weihanglo]

@BatmanAoD this is implemented in https://github.com/rust-lang/cargo/pull/13626 and there is doc link in the PR description. This PR https://github.com/rust-lang/cargo/pull/14305 also shows the current proposed semantic of matching pre-releases if you're interested.

Mind sharing your use case with minimal repro, if the above can't satisfied your need?