Bug: error parsing Cargo metadata with artifact dependencies

[tsatke]

Description of the issue

Description:

cargo nextest run
error: error parsing Cargo metadata

Caused by:
  `cargo metadata` returned invalid JSON output

Caused by:
  package name cannot be empty at line 1 column 2412

--verbose doesn't provide more info.

I think this is due to artifact dependencies (which I know are unstable, but it would be nice if this could handle or at ignore those).

Steps to reproduce:

1. Use a project with artifact dependencies (for example: https://github.com/tsatke/nextest-repro-2407 )
2. cargo nextest run

Expected outcome

Tests should be run

Actual result

cargo nextest run
error: error parsing Cargo metadata

Caused by:
  `cargo metadata` returned invalid JSON output

Nextest version

cargo-nextest 0.9.98 (9d44b7418 2025-06-06)
release: 0.9.98
commit-hash: 9d44b7418ab8f70091d32086ee4c6d57a9fb2e2e
commit-date: 2025-06-06
host: aarch64-apple-darwin

Additional context

I think this is similar to EmbarkStudios/cargo-about#278 , maybe that link helps.

I'm happy to provide any additional info

[sunshowers]

Thanks for the report -- this change was inherited from a cargo_metadata update to 0.20.0 which started requiring that package names be non-empty.

I'd recommend trying to update your Rust nightly version. If that doesn't work please follow up with cargo_metadata upstream.

[sunshowers]

(This was not documented in the nextest changelog -- my oversight -- but it is documented at https://github.com/guppy-rs/guppy/blob/main/guppy/CHANGELOG.md#changed. In my testing, the bindeps feature no longer produces empty package names.)

[tsatke]

I can reproduce this with the latest nightly.

cargo 1.89.0-nightly (fc1518ef0 2025-06-06)
release: 1.89.0-nightly
commit-hash: fc1518ef02b77327d70d4026b95ea719dd9b8c51
commit-date: 2025-06-06
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.2 vendored)
libcurl: 8.7.1 (sys:0.4.80+curl-8.12.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.5.0 8 Apr 2025
os: Mac OS 15.5.0 [64-bit]

I'm not sure cargo-metadata is the problem, since cargo-about seems to work fine and 0.20.0 is the latest version, if that makes sense? I don't know nextest or about in enough detail to know for sure though.

[sunshowers]

It's definitely from cargo_metadata and specifically this field being validated: https://docs.rs/cargo_metadata/0.20.0/cargo_metadata/struct.NodeDep.html#structfield.name

Please follow up with upstream cargo_metadata.

[sunshowers]

The JSON snippet that's failing to parse:

"deps":[{"name":"","pkg":"path+file:///home/rain/dev/tmp/nextest-repro-2407/subcrate#0.1.0","dep_kinds":[{"kind":"build","target":null,"extern_name":"subcrate","artifact":"bin","bin_name":"subcrate"}]}],"features":[]}

The "name":"" is what's at issue.

[sunshowers]

(Honestly I think this is a bug in Cargo. Not clear to me why it's producing an empty name there — it makes it hard to match up the deps table.)

[benbrittain]

https://github.com/oli-obk/cargo_metadata/commit/73aaebb0770e1919a218dff564659f17da90067c

The newly updated docs here seem to indicate that they aren't planning on changing this behavior

[sunshowers]

Looks like the restriction on empty dependency names has been lifted. I'll update dependent crates this weekend.

[benbrittain]

I did a cursory attempt at building with current guppy HEAD, which does fix the schema error issue (since it already uses the cargo_metadata 0.21) . Looks like there is still some logic around node names that seems unhappy though.

failed to construct package graph: for package 'path+file:///PACKAGE_PATH#0.0.1': no dependencies found matching

[sunshowers]

@benbrittain yep, see https://github.com/guppy-rs/guppy/pull/524.

[sunshowers]

This is now out in cargo-nextest 0.9.101, which will make its way to crates.io within roughly 20 minutes.