patch section in workspace not supported?

[sanmai-NL]

With cargo-tree 0.15.0, a dependency in my workspace member’s Cargo.toml, that is overridden in my root Cargo.toml’s patch section, isn’t listed.

Is this expected behavior? If not, I’ll post more details. If so, this is a feature request. 🙂

[sfackler]

That looks broken - not sure quite what's going on but I'll look into it!

[jebrosen]

I was having this problem (forgot to note what version, sorry), but re-installing today to 0.15.0 appears to be working properly with [patch] sections for me.

[jimblandy]

This bug is still present in cargo-tree 0.16.0. Steps to reproduce:

$ git clone [email protected]:jimblandy/cargo-tree-patch.git
Cloning into 'cargo-tree-patch'...
remote: Counting objects: 18, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 18 (delta 0), reused 18 (delta 0), pack-reused 0
Receiving objects: 100% (18/18), 7.76 KiB | 7.76 MiB/s, done.
$ cargo tree
error: could not find `Cargo.toml` in `/home/jimb/bleah` or any parent directory
$ cd cargo-tree-patch/user
$ cargo tree
user v0.1.0 (file:///home/jimb/bleah/cargo-tree-patch/user)
$ sed -i -e '/patch/,$d' ../Cargo.toml
$ cargo tree
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating registry `https://github.com/rust-lang/crates.io-index`            
user v0.1.0 (file:///home/jimb/bleah/cargo-tree-patch/user)
[dependencies]
└── unreachable v1.0.0
    [dependencies]
    └── void v1.0.2
$ cargo tree --version
cargo-tree 0.16.0
$ 

[sfackler]

Yeah. I think we're using the wrong APIs when loading up the dependency graph, but I poked around for a while and couldn't get it to work properly. The right solution is to call out to cargo metadata instead of linking to cargo as a library, but that's blocked on some missing information: #20.

[sfackler]

Should be fixed by #53.