Skip to content

Instantly share code, notes, and snippets.

@est31
Created Aug 30, 2019
Embed
What would you like to do?

Announcing cargo-udeps

One of the biggest issues that most people have with Rust are the long compile times. One of the reasons why compile times are so long is because many projects use quite a few dependencies from crates.io. Your dependencies have dependencies of their own, and they in turn have dependencies as well, and so on. This results in really big graphs of crates that all have to be compiled by cargo. Sometimes however, a crate actually doesn't use anything of some of its dependencies. Then those dependencies can be removed, resulting in faster builds for that crate. But how do you detect them? Often they sit in Cargo.toml for a long time until someone discovers they are actually unused and removes them (example). This is where cargo-udeps comes in. cargo-udeps is an automated tool to find dependencies that were specified in Cargo.toml but never used in the crate itself.

The name is a short form of "unused dependencies" but it is also a name play on the common ascii-ification of the greek µ letter, standing for "micro-deps". Helping to mitigate the dependency bloat on crates.io is one of the goals of cargo-udeps.

I was inspired to do this project after I wanted to check which dependencies of nushell were unused. I ended up ripgrepping for dependency names one by one and removing them if they didn't appear anywhere in src and then checking whether this caused the build to fail. I then made a PR with the results. Then @eijebong suggested that I should create an automated tool for this.

I pondered over different approaches and for the MVP I ended up with a cargo plugin that reads save-analysis info (that was originally introduced for rls). The solution isn't perfect as it relies on an undocumented feature of rustc's save-analysis, but it actually runs the compiler so it is good at detecting actual usages. Alternative approaches that I want to explore later, like parsing of the crate's source code using syn, have this as a weakness.

After I finished the MVP I ran it on nushell again and I actually found two more crates that could be removed/disabled.

This 0.1.0 MVP release is meant to gauge interest in the ecosystem in such a tool. If there is demand, I want to invest more time into it and explore some of the more time-consuming approaches like using a syn parser. This would give faster performance, avoid having to compile the dependencies of the crate, and work on stable Rust instead of just nightly.

To install cargo-udeps, do cargo install cargo-udeps. Then you can run it on your project by doing cargo +nightly udeps.

@the8472
Copy link

the8472 commented Sep 5, 2019

I see. And this is a tangent, but what if such a callback told cargo exactly which symbols it would need from the other crate? then it wouldn't have to build unusued modules and such, which might make up for the delay of starting later. cargo check is already relatively fast, so it should be able to gather the necessary metadata for partial dependency compilation. A whole crate not being compiled would just be the limit case of that.

@faern
Copy link

faern commented Sep 6, 2019

This is a really needed tool! Awesome. Should definitely be the default in cargo to perform this analysis. I already found one unused dependency over here :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment