oli-obk / cargo_metadata Goto Github PK

I'm hoping to use cargo_metadata for cargo-edit to get a full list of all the direct dependencies of crates in a workspace.

For this to be useful, however, it would be nice if Dependency were to expose the kind and version.

@ref rust-lang/rustfmt#2379

The basic idea is that simply reporting failure rather than an error message creates confusion when this crate is used downstream. One proposal is to capture stderr and include that as the returned err.description.

Getting an extremely strange compile error, strange as in it seems it should happen all of the time, but only happens when this crate is a transitive dependency?

error[E0252]: the name `Deserialize` is defined multiple times
 --> /home/jake/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo_metadata-0.11.0/src/dependency.rs:5:20
  |
4 | use serde::{Deserialize, Deserializer};
  |             ----------- previous import of the macro `Deserialize` here
5 | use serde_derive::{Deserialize, Serialize};
  |                    ^^^^^^^^^^^--
  |                    |
  |                    `Deserialize` reimported here
  |                    help: remove unnecessary import
  |
  = note: `Deserialize` must be defined only once in the macro namespace of this module

This error seems to be completely valid, but doesn't appear when you just compile this crate alone or when it's a direct depdency, as far as I can tell.

I'll open up a PR to fix it.

cargo metadata now emits edition information (see rust-lang/cargo#5834).

I'm not sure what your policy is for nightly features, but I'd be happy to add this if you want.

Currently Source(String) doesn't expose any way to get the inner String other than than doing something nasty like format!(), would be nice to either expose the inner String as pub or at least provide an as_ref()/as_str() to retrieve a reference.

I have been struggling to get wasm-pack to run. I keep getting and OS Error 5: Access Denied message. wasm-pack issue

After doing some digging I found that the error seems to be originating from a call to cargo_metadata

What might cause this to throw this error? My rust is version rustc 1.44.0 with the windows toolchain stable-x86_64-pc-windows-msvc. I have tried changing permissions on files and folders that are relevant to the project.

All, NoDefault, and Features are in an enum, making them mutually exclusive. This would be fine except that they are then stored in MetadataCommand as a Option<CargoOpt>. This prevents doing --no-default-features --features "one-of-the-default".

Cargo.toml:

[workspace]
members = [ "crates/*", "xtask/" ]

[profile.dev]
debug = 1 # only line info

[profile.release]
incremental = true
debug = 1 # only line info

[patch.'crates-io']

The Cargo.toml is from rust-analyzer:
https://github.com/rust-analyzer/rust-analyzer/blob/5376c769f0cb6076c4862e728af042bb563a5051/Cargo.toml

cargo_metadata seems to fail to resolve the regex inside members = [ "crates/*", "xtask/" ]:
Err(CargoMetadata { stderr: "error: failed to read `/tmp/ttest/crates/*/Cargo.toml`\n\nCaused by:\n No such file or directory (os error 2)\n" })
Cargo does not seem to have a problem doing so.

cargo-metadata 0.8.2

in cargo-cache, I use cargo-metadata to get the target-dir of a project, roughtly like this:

  let target_dir = MetadataCommand::new()
        .manifest_path(&manifest)
        .exec().unwrap().target_directory

and it seems that cargo-metadata stalls while doing that if I write to the $CARGO_HOME (for example by doing a cargo fetch) at the same time.
This seem unreasonable since the dep source cache and a local projects target dir don't need to be blocking each other I think?

While tinkering with rust-lang/rust-clippy#4517 I noticed that package.readme is defined as Option<String>. However, documentation claims it is actually a filename, so PathBuf could be more appropriate in this case (just like package.license-file).

I just found the cause of rustwasm/wasm-pack#637. I thought the system might not have found the manifest file, but it turned out the error occurred because the cargo executable could not be found. cargo is in my path, but the invalid cargo environment variable took precedence.

Would it be possible to have a custom error variant that is returned when the executable doesn't exist?

Currently, manifest only accepts an Option<&str>. This is all well and good. However, I've only got an Option<String>, and cannot find any means of converting it to the required format.

Unless I've missed something obvious, I think the easiest solution here would be to accept an Option<S: Into<String>> here.

I'm using the following to parse cargo build --message-format=json. I see other crates have a similar redefinition of this, for example assert_cmd.

They are apparently stable. I'm wondering if it's worth making cargo_metadata the canonical place for these?

use cargo_metadata::Target;

// https://github.com/rust-lang/cargo/blob/c24a09772c2c1cb315970dbc721f2a42d4515f21/src/cargo/util/machine_message.rs
#[derive(Deserialize, Debug)]
#[serde(tag = "reason", rename_all = "kebab-case")]
pub enum Message {
	CompilerArtifact {
		#[serde(flatten)]
		artifact: Artifact,
	},
	CompilerMessage {},
	BuildScriptExecuted {},
	#[serde(skip)]
	Unknown, // TODO https://github.com/serde-rs/serde/issues/912
}

#[derive(Deserialize, Debug)]
pub struct Artifact {
	pub package_id: String,
	pub target: Target,
	pub profile: ArtifactProfile,
	pub features: Vec<String>,
	pub filenames: Vec<PathBuf>,
	pub fresh: bool,
}

#[derive(Deserialize, Debug)]
pub struct ArtifactProfile {
	pub opt_level: String,
	pub debuginfo: Option<u32>,
	pub debug_assertions: bool,
	pub overflow_checks: bool,
	pub test: bool,
}

trim_left_matches has been (or going to be soon?) deprecated in favor of trim_start_matches.
Perhaps the documentation should be updated to use the latter?

The repository contains no tag for the v0.8 release.

Cargo metadata does not respect the .cargo/config if it is executed from outside the directory in which the Cargo.toml resides.

For my project I had a custom registry defined in the .cargo/config and used it in the Cargo.toml.

If I have a workspace with a binary crate and another crate declaring a dependency on that binary crate (notwithstanding whether that makes sense), cargo metadata outputs a depedency with name null. Since cargo-metadata expects dependencies to always have a name, it fails to deserialize that metadata.

Here's a minimal reproduction: https://github.com/flodiebold/cargo-metadata-bug

As of #15, metadata() still takes an Option<&str>, but expects it to be of the form e.g. Some("Cargo.toml"). See https://github.com/oli-obk/cargo_metadata/blob/master/tests/selftest.rs#L21

Looking at the example, though, I think #15 may have introduced a breaking change. Unless I'm misreading the example (and code), it was previously expecting something of the form e.g. Some("--manifest_path=Cargo.toml").

let manifest_path_arg = std::env::args().skip(2).find(|val| val.starts_with("--manifest-path="));
let metadata = cargo_metadata::metadata(manifest_path_arg.as_ref().map(AsRef::as_ref)).unwrap();

More irritating is that this is the sort of breaking change that nobody will notice until they try and pass in a manifest path - there have been no changes to the types.

I don't know what the right answer is. Maybe it's worth reverting this change? Maybe we could switch to Option<Path> so that people notice the change when their code fails to compile?

Also, I'm not convinced the old code (or example) supports providing the manifest path as --manifest-path PATH (i.e. with the '=' optional, which is what cargo does using docopt).

While the Package contains a list of direct dependencies, how can I match a Dependency to a corresponding Package? I initially considered using NodeDep which contains a PackageId, but the names in NodeDep do not always match the names in Dependency (even if considering renames).

For example:
backtrace's list of NodeDeps contains "backtrace_sys", while it's list of Dependencys contains only "backtrace-sys" and rename is None.

This could also be a bug/issue with cargo metadata itself, or I'm just using it incorrectly - especially since the lengths of the two lists often don't match.

My current workaround (which feels quite hacky, but works so far), where root_node is a Node and root_package is the corresponding Package:

for dep in root_node.deps.iter() {
	let dependency = root_package.dependencies.iter().find(|dependency| {
		dependency.rename.as_ref() == Some(&dep.name)
			|| (dependency.rename == None && dependency.name == dep.name)
			|| format!("{}", dep.pkg).starts_with(&dependency.name)
	});
}

The following invocation:

let deps = &cargo_metadata::metadata_deps(Some(Path::new("Cargo.toml")), true).unwrap();

throws the error:

"missing field workspace_root"

I assume this may be related to the field "workspace_root" in the Metadata structure being a String rather than a Option<String> ?

The Cargo.toml itself is valid.

Consider switching to a error type which is Sync (so that it can be turned into a Failure error).

Fail requires Send+Sync+'static but error chain errors are not Sync (due to the way they handle backtraces if I remember correctly).

In cargo's output, package id is opaque identifier. The proper way to extract package's name, version and stuff is to look it in the packages array by the id and inspect the fields. WorkspaceMember instead splits the id. This works at the moment, but this is not guaranteed to work.

Looks like cargo that comes with nightly renders metadata a bit differently and causes test failure

The metadata JSON has full package ids on workspace_members list. During creation of WorkspaceMember it is parsed into 3 fields and the original value is dropped. It would be nice to have the original id there too. It would make finding workspace packages on packages list easier.

Target has grown a new field to accommodate use case when you have an example which is compiled as a library. See rust-lang/cargo#3840 for some details.

It seems to be the norm to provide a LICENSE file. This repo doesn't seem to have one (though Cargo.toml specifies MIT).

Maybe copy https://github.com/rust-lang/rust/blob/master/LICENSE-MIT?

The Platform type in cargo_metadata is currently an opaque string. Recently, Cargo's cfg() parsing has been extracted into a separate crate: cargo-platform. I'm filing this issue to let people know about it, and to see if it would be worthwhile to use its Platform type in cargo_metadata instead of just an opaque string. This would provide a way for users to get structured access to the cfg expressions.

I'm not sure if it would actually be useful, though, since correlating cfg expressions with the compiler is a nontrivial task. There is an example showing what needs to be done in matches.rs. The --filter-platform flag was added to cargo metadata as an alternate solution that makes Cargo do the heavy lifting. I think the filter flag probably covers most use cases people would have for inspecting the platform, but maybe there are still cases where it would be useful? (I personally can't think of any.)

I got the deserialisation message Err(Error("expected value", line: 3, column: 1)) when running parse_messages on the piped output of: cargo +nightly test --message-format json --manifest-path tarpaulin/tests/data/doc_coverage/Cargo.toml --doc

Below is the json (but prettified):

{
   "reason":"compiler-artifact",
   "package_id":"doc_coverage 0.1.0 (path+file:///home/xd009642/code/rust/tarpaulin/tests/data/doc_coverage)",
   "target":{
      "kind":[
         "lib"
      ],
      "crate_types":[
         "lib"
      ],
      "name":"doc_coverage",
      "src_path":"/home/xd009642/code/rust/tarpaulin/tests/data/doc_coverage/src/lib.rs",
      "edition":"2018",
      "doctest":true
   },
   "profile":{
      "opt_level":"0",
      "debuginfo":2,
      "debug_assertions":true,
      "overflow_checks":true,
      "test":false
   },
   "features":[

   ],
   "filenames":[
      "/home/xd009642/code/rust/tarpaulin/tests/data/doc_coverage/target/debug/deps/libdoc_coverage-c0b9eafea90c1625.rlib",
      "/home/xd009642/code/rust/tarpaulin/tests/data/doc_coverage/target/debug/deps/libdoc_coverage-c0b9eafea90c1625.rmeta"
   ],
   "executable":null,
   "fresh":false
}

I'd like to use cargo-metadata for rust-semverver instead of relying on cargo.

I need to be able to:

• construct a (package, workspace) pair for the local directory
• construct a (package, workspace) pair by fetching a package of a specific name and version (downloading the package, etc.)
• compile a (package, workspace) pair, e.g., producing an rlib, with some RUSTFLAGS (equivalent operation to cargo::ops::compile(&workspace, &opts) ), and obtain the path to the rlib of the package as well as the path to the deps output directory

Which of these operations would belong in cargo_metadata and which ones would not ? What should I do about the operations that do not belong here ? (e.g. where should I put these?)

Currently, all the lists produced by cargo metadata are converted into Vecs. However, this is probably not correct for unordered collections.

dependencies is the main example of this unordered behaviour, and should probably be a HashSet<Dependency>. I haven't checked to see if this is true for any other fields.

It looks like workspace_members field is not exposed despite being reported by cargo metadata

Hi. I like to do builds out of tree, with the actual source code not writeable by the build process. This is achieved with cargo --manifest-path=..../Cargo.toml --target-dir=target.

NB revised description follows

Unfortunately, if a parent of the source directory contains a cargo config, the cargo run by the cargo_metadata tests picks that up, rather than the one from the build directory. This is because cargo changes directory to the source directory before running the tests. rust-lang/cargo#8148

If I make a linkfarm it does work, but this is of course not particularly desirable.

See transcript below.

Regards,
Ian.

rustcargo@zealot:~/Rustup/Tau/cargo_metadata$ cargo test --manifest-path=/home/ian/Rustup/Tau/cargo_metadata/Cargo.toml --target-dir=target
   Compiling proc-macro2 v1.0.10
   Compiling serde v1.0.106
   Compiling unicode-xid v0.2.0
   Compiling syn v1.0.17
   Compiling ryu v1.0.4
   Compiling semver-parser v0.7.0
   Compiling itoa v0.4.5
   Compiling quote v1.0.3
   Compiling serde_derive v1.0.106
   Compiling serde_json v1.0.51
   Compiling semver v0.9.0
   Compiling cargo_metadata v0.9.1 (/home/ian/Rustup/Tau/cargo_metadata)
    Finished test [unoptimized + debuginfo] target(s) in 17.47s
     Running target/debug/deps/cargo_metadata-1d5f192e04387cf6

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/selftest-b294874640311415

running 6 tests
test cargo_path ... ok
test error1 ... ok
test error2 ... ok
test metadata ... ok
test metadata_deps ... FAILED
test builder_interface ... FAILED

failures:

---- metadata_deps stdout ----
thread 'metadata_deps' panicked at 'called `Result::unwrap()` on an `Err` value: CargoMetadata { stderr: "error: failed to get `semver` as a dependency of package `cargo_metadata v0.9.1 (/home/ian/Rustup/Tau/cargo_metadata)`\n\nCaused by:\n  failed to load source for dependency `semver`\n\nCaused by:\n  Unable to update registry `https://github.com/rust-lang/crates.io-index`\n\nCaused by:\n  failed to update replaced source registry `https://github.com/rust-lang/crates.io-index`\n\nCaused by:\n  failed to read root of directory source: /usr/share/cargo/registry\n\nCaused by:\n  No such file or directory (os error 2)\n" }', tests/selftest.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- builder_interface stdout ----
thread 'builder_interface' panicked at 'called `Result::unwrap()` on an `Err` value: CargoMetadata { stderr: "error: failed to get `semver` as a dependency of package `cargo_metadata v0.9.1 (/home/ian/Rustup/Tau/cargo_metadata)`\n\nCaused by:\n  failed to load source for dependency `semver`\n\nCaused by:\n  Unable to update registry `https://github.com/rust-lang/crates.io-index`\n\nCaused by:\n  failed to update replaced source registry `https://github.com/rust-lang/crates.io-index`\n\nCaused by:\n  failed to read root of directory source: /usr/share/cargo/registry\n\nCaused by:\n  No such file or directory (os error 2)\n" }', tests/selftest.rs:66:13


failures:
    builder_interface
    metadata_deps

test result: FAILED. 4 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out

error: test failed, to rerun pass '--test selftest'
rustcargo@zealot:~/Rustup/Tau/cargo_metadata$ lndir /home/ian/Rustup/Tau/cargo_metadata/. .
/home/ian/Rustup/Tau/cargo_metadata/./src:
/home/ian/Rustup/Tau/cargo_metadata/./tests:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/bdep:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/bdep/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/windep:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/windep/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/featdep:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/featdep/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/namedep:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/namedep/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/path-dep:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/path-dep/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/devdep:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/devdep/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/benches:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/src:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/src/bin:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/tests:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/examples:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/oldname:
/home/ian/Rustup/Tau/cargo_metadata/./tests/all/oldname/src:
rustcargo@zealot:~/Rustup/Tau/cargo_metadata$ cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.10s
     Running target/debug/deps/cargo_metadata-1d5f192e04387cf6

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/selftest-b294874640311415

running 6 tests
test cargo_path ... ok
test error1 ... ok
test error2 ... ok
test metadata ... ok
test metadata_deps ... ok
test builder_interface ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/test_samples-3e73418aed7f2793

running 4 tests
test alt_registry ... ok
test old_minimal ... ok
test current_dir ... ok
test all_the_fields ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

   Doc-tests cargo_metadata

running 4 tests
test src/lib.rs - Package::metadata (line 280) ... ok
test src/lib.rs -  (line 31) ... ok
test src/lib.rs -  (line 10) ... ok
test src/lib.rs -  (line 48) ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

rustcargo@zealot:~/Rustup/Tau/cargo_metadata$ 

Something like fn root_package(&self) -> Option<&Package>. This would make it much easier to access the root package for which the metadata was queried.

@oli-obk btw, thanks for the excellent project here. I'm happy to hack on this (it is dead simple).

Currently, it is really hard to write tests using the types exposed in this library. This is because code outside of the library cannot construct them -- as far as I can see.

The types follow roughly this pattern, Metadata is just an example:

#[derive(Clone, Serialize, Deserialize, Debug)]
/// Starting point for metadata returned by `cargo metadata`
pub struct Metadata {
    /// A list of all crates referenced by this crate (and the crate itself)
    pub packages: Vec<Package>,
    /// ... some more fields ...
    #[doc(hidden)]
    #[serde(skip)]
    __do_not_match_exhaustively: (),
}

This keeps users of this library from getting compile errors when fields are added. It also keeps them from constructing these types.

It would be nice to have a way to construct these values with default values and then override only the values that are needed to be overridden.

A current workaround would be to deserialize the wanted values from JSON but that seems rather silly.

It would make using cargo_metadata::Error substantially easier.

Would it make sense, perhaps, to switch over to error-chain?

At the Cargo Team Meeting today we discussed the importance of crates like this one. We decided to reach out to discuss how best to work together. How can we insure that the projects are kept smoothly uptodate with each other? What else can the Cargo team do to make sure we don't accidentally break this project? How can the Cargo team make sure that changes get included here promptly? Can we / Should we share code?

cc @ehuss who already got started in #61
and @dwijnand had some suggestions in rust-lang/cargo#6534

Also this idea should be expanded to Cargos other outputs. Should that be done here, or in some other existing crate, or in some new Cargo Team maintained crate?

cc @epage as this relates to the discussion in #45

cargo metadata output cannot be parsed by this crate when the environment variable CARGO_PROFILE is set. See https://github.com/rust-lang/cargo/blob/2ed31b02a80ad89e40864ecbed30f02992566e3d/ARCHITECTURE.md#logging. I get an error message "invalid type: integer 0, expected struct Metadata at line 1 column 11" with cargo_metadata version 0.7.3.

https://docs.rs/cargo_metadata/0.11.2/cargo_metadata/struct.Package.html

A package is not the same as a crate (https://doc.rust-lang.org/book/ch07-01-packages-and-crates.html); a package contains one or more crates. The thing that the Package struct refers to as "targets" are actually what are built into "crates" (though "targets" seems to be the correct Cargo term there).

I believe the field is due to be released in Rust 1.24.

Not quite sure where to find it yet, but it should show up as something like this in the target list:

{
    "kind": [
        "custom-build"
    ],
    "crate_types": [
        "bin"
    ],
    "name": "build-script-build",
    "src_path": "/Users/eric/Proj/rust/cargo/scratch/b/build.rs",
    "edition": "2018"
}

I THINK right now it just shows up as DependencyKind::Unknown, but adding support for it should hopefully not be too painful. I'll see what I can come up with. All I actually want so far is whether a build script is present and what the path to it is, though someday I probably want to get the dev-dependencies of it too.

I wonder if it makes sense to make cargo_metadata::Source an enum that represents whether the crate is a registry, path or git dependency.

That way users wouldn't have to parse the string manually.

Particularly, I want the ability to run a nightly cargo with some -Z commands. If you want this, when I implement it I'll submit a PR.

Hello, I discovered one test is failing on my machine.

• macOS 10.15.6 (19G73)
• cargo 1.44.1 (88ba85757 2020-06-11)
• rustc 1.44.1 (c7087fe00 2020-06-17)

Here's test result.

running 6 tests
test cargo_path ... ok
test error1 ... ok
test error2 ... ok
test metadata ... FAILED
test metadata_deps ... ok
test builder_interface ... ok

failures:

---- metadata stdout ----
thread 'metadata' panicked at 'assertion failed: `(left == right)`
  left: `"/Users/Dev/Workshop/aliens/cargo_metadata/target"`,
 right: `"/Users/Dev/.build"`', tests/selftest.rs:25:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    metadata

test result: FAILED. 5 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

Here's source code for the broken part.

assert_eq!(
    current_dir().unwrap().join("target"),
    Path::new(&metadata.target_directory)
);

IMO, this is because I overridden target-dir using user-wide config file at $HOME/.cargo/config.

Here's my config file content.

[build]
target-dir = ".build"

It seems the test should consider this configuration or need to be updated.

I tried cargo test --target-dir target, but it still fails. I'm not sure what to do.

rust-lang/cargo#8002

rust-lang/cargo#7977

The new feature resolver has turned metadata inadequate for some purposes, so --unit-graph was introduced.

I'd like to filter messages with Itertools::unique and/or put them to hash table, but Message doesn't implement required traits.

Hi, this issue may sound a bit strange, let me explain:

• We have many servers which use SGX enclaves. For us, it is natural that the rust package corresponding server which requires an enclave, should ensure that the enclave gets built. But it is not a natural rust dependency, the enclave is compiled as a shared library which is then loaded into the CPU via Intel APIs, and it has special requirements like, it cannot link to libstd.
• This means that we have server packages, whose build.rs shells out to cargo in order to build the enclave package. That invocation takes place in a different cargo workspace.
• In order to get correct incremental builds, we want to emit cargo:rerun-if-changed directives from that build.rs, corresponding to any local packages depended on by the enclave.
• In order to get those paths, we want to use cargo_metadata to find any local packages depended on by the enclave, which works :)
• Unfortunately, because cargo_metadata depends on serde_json, it brings the std feature into serde and then breaks the enclave build. This feature unification across dependencies and build-dependencies is a long-standing cargo bug, with no fix in sight: rust-lang/cargo#4866

After some deliberation, what I have done now is clone cargo_metadata and republish it on crates.io as alt_cargo_metadata. I have also republished alt_serde and alt_serde_json, and patched their Cargo.toml's to depend on alt versions of each other. Cargo allows renaming dependencies via package = so the code still refers to serde, but Cargo does not unify features between serde and alt-serde, so our build can limp along.

What I'd like to ask is, would you consider accepting a patch that migrates cargo_metadata away from serde_json towards something that does not use std, and specifically, doesn't require serde/std? It seems like a design flaw that serde_json cannot be used at all without serde/std, it seriously limits its usefulness.

I'd also be interested if you think there's a better way to track dependencies of a cargo invocation made from a build.rs script than using this package -- I guess that you are mainly interested in supporting cargo subcommand tools, so maybe this use is out of scope?

Thanks!

cargo build --build-plan -Z unstable-options emits a build plan a nested json. It would be great if cargo_metadata could deserialize the build plan into structs. It should be possible to mostly copy the definitions from https://github.com/rust-lang/cargo/blob/master/src/cargo/core/compiler/build_plan.rs.

This field is currently present, but non-public. Could it be made public?

There currently seems to be no way to figure out if a bin/lib target has tests enabled. Would be great if that information was made available -- I think that is required to solve rust-lang/miri#700.