Closed andrewrk closed 7 years ago
Seems like a cool idea! (also wow that's a lot of dependencies)
Cargo does support custom subcommands by having cargo-foo
located in your $PATH
(allowing cargo foo
), so we don't necessarily have to have this support in-tree.
I built one: https://github.com/jakub-/cargo-ls.
Happy to contribute it as a built-in command in case we think it has high enough utility to be included.
I'd love to see this built-in. This is something I've wanted on multiple occasions. But I also want a bit more info about each dependency (this could be put behind a --verbose
flag). Specifically, I want to know:
cargo update
, if it differs from the current version and from the newest version.It would also be good to have some specific support for packages that are depended upon by multiple paths. In such a case, a package may be constrained to an older version, which isn't apparent when looking at one of the dependency paths, which can be confusing if the reader doesn't realize there's multiple dependencies on the same crate with different version requirements.
I guess what I'd actually like to see is a command cargo deps
that by default just lists each crate in order, with the aforementioned info, along with a list of crates it depends on and crates that depend on it. The tree-like output in the ticket description could then be yielded with cargo deps --tree
(but I'm not really a fan of that as the default output because it has to duplicate each crate that's depended-on by multiple other crates, e.g. in the example tree the npm
package request
is listed twice).
hey @kballard @andrewrk cargo-edit has a pretty nice tree view. its not all the information I think @kballard wants but its a good start. crates page
Also there is a new command metadata that is in master which might be of interest.
Output the resolved dependencies of a project, the concrete used versions including overrides, in machine-readable format.
Thanks! becker
https://crates.io/crates/cargo-tree is another implementation of this.
As implementations exist of this externally, closing.
@alexcrichton With "cargo ls" being gone and "cargo tree" not being able to compile,is there any chance that this is going to be reopened? I have a project where some dependencies pulls in tokio, which doesn't compile (as usual) and I would like to remove that dependency, but it's really not easy to figure out which one causes this.
@philippludwig what issue are you having with cargo-tree not compiling? It seems to work for me.
cargo-tree
does not compile on macOS because it tries to install openssl-sys
, which bails as macOS ships with a really old OpenSSL.
I'm rather curious as to why cargo-tree
depends on this. If only there was some tool I could use to visualize its dependency graph...
I'm guessing it pulls it in via the dependency on cargo
, though that lists it as optional.
@philippludwig what issue are you having with cargo-tree not compiling? It seems to work for me.
It failed with some random linker error, but after I deleted the ~/.cargo
folder, I can't reproduce it anymore. Now it compiles fine, thanks for your support!
for anyone else stumbling on to this from google searching for "cargo list dependencies", this is now built into cargo
, use via cargo tree
- https://doc.rust-lang.org/cargo/commands/cargo-tree.html
(openssl still doesn't show up in the tree)
One use case: I have a failing to compile dependency and I want to know how exactly I depend on it.
As an example, npm has the
npm ls
command: