Description
Describe the problem you are trying to solve
We're running into some challenges over in rustfmt
due to the output of the cargo metadata
command missing the source
path for local dependencies when using the --no-deps
flag with cargo metadata
.
Describe the solution you'd like
Ideally, in the output of cargo metadata --no-deps
, the source field for local dependencies would include the path value instead of being null.
Notes
cargo fmt
uses the cargo metadata
command to get info about the workspace to pass as inputs to rustfmt
. One of the modes cargo fmt
supports is --all
which allows rustfmt
to also format local dependencies. In order to be able to do this, cargo fmt
needs to be able locate the manifest path for the local dependency.
However, the serialization for Dependency results in the path value for local dependencies being stripped, so in the output from cargo metadata
, local dependencies have "source": null,
and the output of cargo metadata --no-deps
does not contain any other info cargo fmt
can use to definitively determine the manifest path of the local dependency. This is problematic for cargo fmt
, especially since the directory name where the local dependency resides and the name of the dependency can differ - rust-lang/rustfmt#3643
We've been working around the missing data by running cargo metadata
(without the --no-deps
flag) since that output does allow us to correctly determine the manifest_path
value for local dependencies. However, running cargo metadata
without --no-deps
is creating some other challenges for us, and we'd really like to be able to get everything needed via cargo metadata --no-deps
.
AFAICT, for path-based dependencies, the value is stripped deliberately from the serialized output:
cargo/src/cargo/core/source/source_id.rs
Lines 401 to 412 in 0fe1638
I'm sure that's done for good reason, though I'm wondering/hoping that those reasons may not be applicable for cargo metadata
output and that it would be possible to keep that value for local path-based dependencies included just in the cargo metadata
output (perhaps by using different struct representations)?
cc @topecongiro