feat(cargo-lock): support lockfile v4

[weihanglo]

In 1.78.0 Cargo introduce v4 lockfile:
rust-lang/cargo#12852

The v3-to-v4 change is minimal: encode URL params with URL encoding.
However, roundtrip test failed because v4 we can only have one
serialization implementation at a time.

I don't know how to proceed. Maybe we could

• Make v4 serialization the default when it becomes the default in Cargo
• Provide API for people to generate different versions of lockfiles.
• Work with upstream Cargo with an in-tree pacakge for lock serialization. (This is on me?)

Opened this PR for discussion.

[weihanglo]

Generated from https://github.com/weihanglo/toml/tree/a-_%2B%23%24)z.

[weihanglo]

Hmm… missing some commits. Wait a sec.

[weihanglo]

Generated from https://github.com/weihanglo/rust-url/releases/tag/a-_%2B%23%24)z.

[weihanglo]

Note that in 3bcf68b, a bug was identified, unrelated to lockfile v4. See the commit message for more.

[tarcieri]

Provide API for people to generate different versions of lockfiles.

@weihanglo it already supports this. Lockfile::version is consulted at serialization time and used to generate different versions of lockfiles.

[weihanglo]

Provide API for people to generate different versions of lockfiles.

@weihanglo it already supports this. Lockfile::version is consulted at serialization time and used to generate different versions of lockfiles.

Yeah but not for SourceId. We need to make SourceId aware of resolve version. On the Cargo side there is an EncodableSourceId doing that job. I don't think this cargo-lock crate is particularly interested in copying over the wrapper from there.

[tarcieri]

A lot of the code has been copied from there. It would be good to follow the same approach they're using.

[weihanglo]

Work with upstream Cargo with an in-tree pacakge for lock serialization. (This is on me?)

I am mostly thinking through this. The Cargo team has published a new crate https://crates.io/crates/cargo-util-schemas providing basic serialization schemas for common types. I wonder if we could get there so cargo-lock can be a thin tool built upon crates from Cargo.

[tarcieri]

Sure, that looks potentially useful

[tarcieri]

FWIW I took a look at cargo-util-schemas. It sure would be nice to use several types defined there, like PackageIdSpec, SourceKind and GitReference, however for those in particular they'd be nice to have as part of the public API, and unfortunately the latter two are enums so they can't really be wrapped in newtypes.

Unfortunately, it doesn't seem ready for that as they just released semver breaking changes a week ago.

In the meantime it doesn't otherwise seem to have types relating specifically to Cargo.lock, only Cargo.toml.

[weihanglo]

In the meantime it doesn't otherwise seem to have types relating specifically to Cargo.lock, only Cargo.toml.

That's true.

I think maybe we should just copy over from there one more time 😞.

[weihanglo]

@tarcieri this is ready for review. Take your time :)

Most of the code are copied or adapted from cargo the lib.

Note that I've identified a bug not related to lockfile format version: #1206 (comment)

[tarcieri]

I'm busy for the rest of the week but will try to look this weekend

[71]

Note for anyone stumbling on this PR when getting "parse error: invalid Cargo.lock format version: `4`" (and who control the workspace whose Cargo.lock is causing problems): in the meantime you can add

rust-version = "1.81" # ensure it stays in lockfile v3

to the Cargo.toml to prevent Cargo from upgrading the lockfile format to v4 (source).

[tarcieri]

@weihanglo thank you!