Merged
Conversation
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.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
matklad
commented
Aug 7, 2018
| } | ||
|
|
||
| pub fn dependencies_listed(&self, from: &PackageId, to: &PackageId) -> &[Dependency] { | ||
| pub fn extern_crate_name( |
Contributor
Author
There was a problem hiding this comment.
This should also help racer which does this mapping manually atm: https://github.com/racer-rust/racer/blob/a89145e9deb5efd2b9fb75826e556a6c6f9d044d/src/racer/project_model.rs#L155-L158
Contributor
Author
|
This is a second attempt at #5461 The primary difference is that instead of just dumpling a |
Member
|
@bors: r+ 👍 |
Contributor
|
📌 Commit 39b1f75 has been approved by |
Contributor
bors
added a commit
that referenced
this pull request
Aug 7, 2018
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.
Contributor
|
☀️ Test successful - status-appveyor, status-travis |
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Aug 15, 2018
Update cargo - Update transitioning url (rust-lang/cargo#5889) - Resolve some clippy lint warnings (rust-lang/cargo#5884) - Don't kill child processes on normal exit on Windows (rust-lang/cargo#5887) - fix a bunch of clippy warnings (rust-lang/cargo#5876) - Add support for rustc's --error-format short (rust-lang/cargo#5879) - Support JSON with rustdoc. (rust-lang/cargo#5878) - Fix rustfmt instructions in CONTRIBUTING.md (rust-lang/cargo#5880) - Allow `cargo run` in workspaces. (rust-lang/cargo#5877) - Change target filters in workspaces. (rust-lang/cargo#5873) - Improve verbose console and log for finding git repo in package check (rust-lang/cargo#5858) - Meta rename (rust-lang/cargo#5871) - fetch: skip target tests when cross_compile is disabled (rust-lang/cargo#5870) - Fully capture rustc and rustdoc output when -Zcompile-progress is passed (rust-lang/cargo#5862) - Fix test --example docs. (rust-lang/cargo#5867) - Add a feature to build a vendored OpenSSL (rust-lang/cargo#5865)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some work towards #5583
Previously,
cargo metadataexposed dependencies info as a graph ofpackage id without any additional information on edges.
However, we do want to add some data to edges, including for example,
package renames and
cfginfo.Internally, the edges info is represented as a
Vec<Dependnecy>. Wecould 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
idandrenameinfo only. It should bepossible 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.