Would you be open to adding other tools to the image?

[jaskij]

Personally, I believe that running cargo install as part of a pipeline is an antipattern - it makes the jobs much longer, for little to no benefit.

That's why I maintain my own image on top of rust which I update as needed.

It would be amazing if popular and powerful crates were added to upstream images. At the moment, I can name three that I would like to see included:

• cargo-deny - for auditing dependencies and linting Cargo.toml
• cargo-hack - for easy testing of features
• cargo-llvm-cov - for coverage

This would be a huge step, and I can see some downsides to this:

• need for regular builds and publishing of at least latest stable version, to keep tools updated (seems to be implemented for nightly?)
• increased burden on maintainers in filtering feature requests what to include and what not to include
• one time: need to set policy on which tools are fine, and which are not

I'm posting this as a general proposal, because from what I can see, the current images only really install the base toolchain and nothing more.

---

Regarding the policy: one thing I'd explicitly deny is duplicates of existing functionality. So, if cargo-deny makes it, cargo-audit would not get added later on because it adds nothing new. Similarly, sccache (#143) doesn't seem to make sense - most CI runners have their own caching and I'm not sure what it would add on top of that. But the specifics are for later, when you decide if you even want to open up to extra tools.

[jac18281828]

Vendor provided tooling should be as trimmed down as possible. Downstream packages and ecosystems tailored to more advanced functionality or code development can offer additional packages to suit their communities.