Format change of ids in 'cargo metadata' with cargo 1.78

[dan-t]

Problem

The format of the id entries in the cargo metadata changes in cargo 1.78.

In cargo 1.76 the format is:
"ansi_term 0.11.0 (registry+https://github.com/rust-lang/crates.io-index)"

In cargo 1.78 the format is:
"registry+https://github.com/rust-lang/crates.io-index#ansi_term@0.11.0"

Both formats are with '--format-version 1'. Is this considered as a breaking change?

Steps

• Execute 'cargo metadata --format-version 1' with cargo 1.76
• Execute 'cargo metadata --format-version 1' with cargo 1.78
• Compare the output

Possible Solution(s)

No response

Notes

No response

Version

No response

[epage]

This is not considered a breaking change.

From https://doc.rust-lang.org/1.76.0/cargo/commands/cargo-metadata.html#output-format

Changing opaque representations — The inner representations of some fields are implementation details. For example, fields related to “Package ID” or “Source ID” are treated as opaque identifiers to differentiate packages or sources. Consumers shouldn’t rely on those representations unless specified.

With the change that was made, we have stabilized the format and you can rely on it, see #12914

[dan-t]

If you want to get the name and version of a package that‘s referenced as a resolved dependency or as a workspace member, you seem to have to parse the id. Therefore I‘m not quite sure that I would consider this as a non breaking change.

[weihanglo]

get the name and version of a package that‘s referenced as a resolved dependency or as a workspace member, you seem to have to parse the id.

For this use case, it doesn't seem to. workspace_members array contains IDs that you can find matching id of a package in packages array.

[dan-t]

On Mon, Mar 04, 2024 at 10:54:21AM -0800, Weihang Lo wrote: For this use case, it doesn't seem to. `workspace_members` array contains IDs that you can find matching `id` of a package in `packages` array.

Yes, you're right. From my point of view this ticket can then be closed.

[kyrias]

While it's true for workspace members, is there currently any reliable way to get the name corresponding to an indirect dependency by the package ID specifier without having to parse it?

Because it seems like there's currently no way to reliably resolve a package_id from the cargo build --message-format json-diagnostic-rendered-ansi output into a package name that works with both <1.77 and >=1.77 cargo versions.

---

Edit: Of course, it doesn't seem to be possible to do this reliably on 1.77 even if we parse the ID since the pkgname fragment is optional for the URI format, so cargo would be within its rights to omit it for e.g. git dependencies.

So it seems to me that unless #7289 is implemented there's still no way to do this without making assumptions on the ID format that cargo will emit.

[epage]

@kyrias can't iterate over Metadata::packages, comparing the id from cargo build with Package::id?

[kyrias]

@epage Metadata::packages doesn't contain indirect dependencies.

[kyrias]

Wait, that's not true, it seems to contain some but not all indirect dependencies? I'm confused now.

[kyrias]

Ah, I guess the issue here is that we're using -Zbuild-std and so we're getting build-script-executed lines for crates which end up not existing in the metadata.

It's a bit unfortunate since it means that you can't use the Index implementation on Metadata if you're building with -Zbuild-std.