Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add dependency graph #1455
It'd be very useful to have a dependency graph so I made a small proof of concept:
I made it by only on front-end side but I think it'd be better to have done it in backend side directly instead (or at least provide an endpoint which would be called when the users want to see the dependency graph).
Any opinions? :)
My initial impressions are:
A bit every time. It doesn't solve any problem on its own but it allows someone to see how much dependencies a crate has. It comes from a debate I had a while ago where someone was saying that between two crates doing the same thing, he/she would take the one with the most (direct) dependencies. Of course I disagree with this statement. Another point is that, the more dependencies you get, the more failure "points" you have.
To put it more simply, it'd help people to realize that dependencies come with a "cost" (let's call it like that) and help them to pick a crate over another one on this criteria too.
Expanded/not-expanded iirc. But this is a proof-of-concept that I wrote quickly so nothing unexpected.
The last entry point normally doesn't have its version determined so it's just version "id" (and again this is just a proof-of-concept).
Just for the current one even though we could add it to dependent crates too.
Navigate yes, normally there are scrollbars (but I was on a mac so we don't see them). Zoom in no. But I know that some other libraries doing the same thing allow to zoom in.
More information of course!
Optional dependencies for sure. Not sure about dev dependencies: should we even have them in this tree? If yes, I suppose I could add checkbox "display dev-dependencies" and have them in a different color.
So for example, your screenshot above is not the resolution cargo will select. The screenshot has
Cargo has logick like this for "the links attribute" (I.E.
It could be that we are Ok with this being different then Cargos algorithm, in which case we need to find a way to make that clear in the UI. It could be that we can find a way to use Cargos implementation directly, (It is very fast in practice, if I do say so myself,) but then we need to do some work to extract the code and protect the server from some attacker finding a slow case before I do. We could make a new implementation that is optimized for
Given the issues that @Eh2406 pointed out, I'm going to close this. We're having enough trouble maintaining the features crates.io has now, and we don't have the bandwidth to maintain new features that might be confusing if they're not exactly right. Thank you for your work, though!