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.

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

Allow removing disabled optional dependencies from graph #24

Closed
johnbchron opened this issue Jun 13, 2024 · 5 comments
Closed

Allow removing disabled optional dependencies from graph #24

johnbchron opened this issue Jun 13, 2024 · 5 comments

Comments

@johnbchron
Copy link

I have a use-case where I'm trying to debug usages of my crates that vary wildly (100s of packages) in size given different feature usages. Right now it seems that even if I use --no-default-features and --features [feature], I can't get optional but disabled dependencies removed from the graph, so it's pretty unreadable. See attached. When analyzed with the same features, cargo tree only shows 20ish packages.

@jplatte
Copy link
Owner

jplatte commented Jun 13, 2024

I'm not sure whether the cargo metadata output has the required information to support this, but I can try to figure that out.

@johnbchron
Copy link
Author

Basically I'd just like to remove packages connected with just a dotted line.

@jplatte
Copy link
Owner

jplatte commented Jun 13, 2024

Yeah I get that. I just tested on one repo and it works for me. Thinking more about it, you might be hitting rust-lang/cargo#7754. Is this in the context of a cargo workspace with more than one package in it? Can you try commenting out the other workspace member entries?

@johnbchron
Copy link
Author

It works if I disable the other workspace members and if I make the graph for a crate that doesn't depend on any other crates in the workspace.

@jplatte
Copy link
Owner

jplatte commented Jun 14, 2024

Right, in that case it is that bug I linked, and there is nothing cargo-depgraph can do, short of hacks that temporarily edit the toml files / create updated copies in a tempdir.

Even then, that would likely only be a partial fix, so I don't think it's reasonable to put that much work in.

I hope the workaround is good enough for your use case.

@jplatte jplatte closed this as not planned Won't fix, can't repro, duplicate, stale Jun 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants