Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Include more information about dependencies in Cargo metadata #5583

Closed
matklad opened this issue May 28, 2018 · 2 comments
Closed

Include more information about dependencies in Cargo metadata #5583

matklad opened this issue May 28, 2018 · 2 comments
Labels
Command-metadata

Comments

@matklad
Copy link
Member

matklad commented May 28, 2018

See #5461 for the reverted attempt at that. Basically, cargo metadata prints not enough information about resolved dependencies.

The bits of info missing from cargo metadata are:
@matklad matklad mentioned this issue May 28, 2018
Merged
@matklad
Copy link
Member Author

matklad commented May 28, 2018

The current plan is to introduce a TargetId thing to allow to refer to a target to a package somehow, and then add per-target dependencies to resolve field of cargo metadata, as a map:

deps: {
  "bin foo": [ { "package_id": "bar", "name": "baz", "platform": "cfg(unix)" }]
}

@gibix gibix mentioned this issue May 31, 2018
Closed
@acmcarther acmcarther mentioned this issue Jun 25, 2018
Closed
@matklad matklad mentioned this issue Jun 26, 2018
Closed
4 tasks
@matklad matklad mentioned this issue Aug 7, 2018
Merged
bors added a commit that referenced this issue Aug 7, 2018
@bors
Auto merge of #5871 - matklad:meta-rename, r=alexcrichton
f67349c 
Meta rename

Some work towards #5583

Previously, `cargo metadata` exposed dependencies info as a graph of
package id without any additional information on edges.

However, we do want to add some data to edges, including for example,
package renames and `cfg` info.

Internally, the edges info is represented as a `Vec<Dependnecy>`. We
could have exposed that directly, but that risks exposing and
ossifying an implementation details.

So instead we collapse a `Vec<Dependnecy>` to a single JSON object,
which at the moment contains `id` and `rename` info only. It should be
possible to add additional fields to that object backwards compatibly.
Such representation does not correspond directly to any internal Cargo
data structure, but hopefully it shouldn't be to hard to maintain.

This representation also does not quite correspond to the "real
world", where dependencies are between crate (cargo targets), and not
packages. However, because each dep edge is a JSON object, adding a
target filter should be possible, which would handle dev-, build-, and
potential future bin-specific dependencies backwards-compatibly.
This was referenced Jul 14, 2019
Merged
Closed
@jsgf jsgf mentioned this issue Aug 22, 2019
Open
bors added a commit that referenced this issue Nov 14, 2019
@bors
Auto merge of #7132 - ehuss:metadata-kind, r=alexcrichton
d0a41be 
Add kind/platform info to `cargo metadata`

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

```javascript
"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.
@tensor-programming tensor-programming mentioned this issue Feb 5, 2020
Merged
12 tasks
@ehuss
Copy link
Contributor

ehuss commented Feb 25, 2020

I'm going to close this as I believe it is finished.

  • The resolve graph now includes dep_kinds which allows you to tell which kinds a dependency is used as.
  • The dep_kinds array includes the "target" field which is the platform for the dependency.
  • The extern crate name is resolve.nodes.deps.name which handles renaming. One common point of confusion is that name is the lib name, with underscores, not the package name.

@ehuss ehuss closed this as completed Feb 25, 2020
@acmcarther acmcarther mentioned this issue Feb 25, 2020
Open
sunshowers added a commit to sunshowers/guppy that referenced this issue Nov 11, 2023
@sunshowers
[guppy] make dependency matching more robust
9b83ef1 
We used to use a heuristic matching algorithm which would check a renamed map
first, then check an original map. We know that that was failing to work in a
few cases, and we encountered one such case in the wild in
nextest-rs/nextest#1090.

Fix that through a few different things:

1. Match up the resolved name correctly, using the same algorithm Cargo uses.
2. Use the `dep_kinds` list introduced in Rust 1.41 (see
   rust-lang/cargo#5583).
sunshowers added a commit to sunshowers/guppy that referenced this issue Nov 11, 2023
@sunshowers
[guppy] make dependency matching more robust
b19fa03 
We used to use a heuristic matching algorithm which would check a renamed map
first, then check an original map. We know that that was failing to work in a
few cases, and we encountered one such case in the wild in
nextest-rs/nextest#1090.

Fix that through a few different things:

1. Match up the resolved name correctly, using the same algorithm Cargo uses.
2. Use the `dep_kinds` list introduced in Rust 1.41 (see
   rust-lang/cargo#5583).
sunshowers added a commit to guppy-rs/guppy that referenced this issue Nov 11, 2023
@sunshowers
[guppy] make dependency matching more robust
820f7a1 
We used to use a heuristic matching algorithm which would check a renamed map
first, then check an original map. We know that that was failing to work in a
few cases, and we encountered one such case in the wild in
nextest-rs/nextest#1090.

Fix that through a few different things:

1. Match up the resolved name correctly, using the same algorithm Cargo uses.
2. Use the `dep_kinds` list introduced in Rust 1.41 (see
   rust-lang/cargo#5583).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Command-metadata
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ehuss @matklad