Add kind/platform info to cargo metadata

[ehuss]

This adds an array "dep_kinds" to the resolve nodes of the cargo metadata output. It looks something like this:

"resolve": {
  "nodes": [
    "id": "cargo 0.39.0 (path+file:///Users/eric/Proj/rust/cargo2)",
    "deps": [
      {
        "name": "bufstream",
        "pkg": "bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
        "dep_kinds": [
          {
            "kind": "dev",
            "target": null
          }
        ]
      },
      {
        "name": "winapi",
        "pkg": "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
        "dep_kinds": [
          {
            "kind": null,
            "target": "cfg(windows)"
          }
        ]
      }
    ]
  ]
}

This allows one to filter the graph based on the dependency kind and platform.

I'm not completely confident that this is the right course, but I can't think of a better design. In particular, it seems a little strange to include all platforms, but features get filtered. This is probably not a problem in practice (one can use --all-features to ensure all features are shown for the top-level packages). Filtering out based on platform is very difficult, because you cannot determine from the resolve alone which nodes will be host vs target. That requires the entire Unit graph. We may expose the Unit graph in the future, but this seems like a useful and simple step.

This is a draft because I wanted to discuss this before moving forward. I'd like to add some more tests.

cc #4632. This doesn't filter based on target, but does expose the target names. As mentioned above, I don't think filtering is possible.
cc #5583. This adds more information.
Closes #3984.
Closes #4631 (I think).

cc @sfackler who filed some of these issues.

[alexcrichton]

Seems like a reasonable approach to me! I agree this is a pretty simple, actionable, and useful step. Also agreed we can add more later!

[matklad]

LGTM!

[sfackler]

Awesome! With respect to platform-specific cfgs, it'd be great to have some utility (whether it's part of the cargo binary or a library) that can evaluate them against a target to see if they match.

[alexcrichton]

Ok I think this has sat long enough, let's see support from the team about adding these fields!

@rfcbot fcp merge

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @ehuss
• @joshtriplett
• @nrc
• @withoutboats

Concerns:

• Document handling of features (and decide if we should emit a features field) resolved by Add kind/platform info to cargo metadata #7132 (comment)
• target should be cfg or similar resolved by Add kind/platform info to cargo metadata #7132 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[bors]

☔ The latest upstream changes (presumably #7186) made this pull request unmergeable. Please resolve the merge conflicts.

[Xanewok]

Looks good!

[bors]

☔ The latest upstream changes (presumably #7214) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

Based on discussion in the cargo meeting:

@rfcbot concern target should be cfg or similar

@rfcbot concern Document handling of features (and decide if we should emit a features field)

[ehuss]

@joshtriplett I took a look at renaming target. I would prefer a term like platform, but I'm concerned that it may cause more confusion, because the term target is already used in Dependency. Although "target" is a little vague, I think it would be preferable to be consistent. Do you feel strongly about using a different name, if it results in an inconsistency?

As for features, there already is a field that tracks features. The comment just above "result" here documents that features are resolved.

[joshtriplett]

@rfcbot resolve target should be cfg or similar

Withdrawn, I didn't know target was already used elsewhere in the same structure for the same purpose, and I agree that we want consistency.

[joshtriplett]

@ehuss I'm not talking about "resolve as if these features were set", I'm talking about annotating the metadata so that it's possible to know which features require which dependencies. Debian, for instance, generates librust-cratename+featurename-dev packages for any featurename that adds additional dependencies.

[ehuss]

cc #7375 and #7376 for extensions/alternatives for platform handling.

[bors]

☔ The latest upstream changes (presumably #7409) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #7376) made this pull request unmergeable. Please resolve the merge conflicts.

[sfackler]

What needs to happen to get this moving again? I'd really like to be able to stop using cargo-the-library in cargo-tree.

[ehuss]

@joshtriplett I'm still not sure I fully understand the use case. Optional dependencies are added by a feature of the same name as the dependency. I put together a small script to show how one can determine which optional dependencies are enabled: https://gist.github.com/ehuss/b91bc1701c1e3de1480d389fe0d9750b

So maybe to make it more clear, given the following manifest:

[package]
name = "foo"
version = "1.0.0"

[dependencies]
bitflags = {version="1.0", optional=true}

[features]
feat1 = ["feat2"]
feat2 = ["bitflags"]

There are three ways in this example to enable the bitflags dependency: --features=bitflags, --features=feat1, and --features=feat2. The script linked above will tell you that bitflags is enabled, but doesn't say which other features may have caused it to be added (it could be several). One could walk the feature graph and determine any other ancestor features that are enabled. For example, given --features=feat1 it could determine that bitflags is enabled by feat1, feat2, and bitflags. It's not really clear to me how that would be useful, though, and I'm not really sure which information you are looking for. Also, a dependency could be enabled by some other package in the graph, so it's really hard to draw a clear distinction of what enables a dependency. But that can be done by creating a reverse-dep graph and looking at all the edges.

Regardless, I think this is still pretty unrelated to adding the kind information to the resolve graph. The metadata contains all feature definitions, and which features are enabled on each package, and I think you can combine the two to understand how they interact.

Also, I think we are displaying as much information as Cargo has. Adding anything else will require changing the internals of how Cargo (particularly the resolver) works. But I don't know what else could be added.

[joshtriplett]

@ehuss Thank you for the explanation. Given how Cargo handles features internally...

@rfcbot resolve Document handling of features (and decide if we should emit a features field)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[alexcrichton]

@bors: r+

[bors]

📌 Commit b65ebc6 has been approved by alexcrichton

[bors]

⌛ Testing commit b65ebc6 with merge d0a41be...

[bors]

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing d0a41be to master...