Potentially add a tooling section

[CosmicHorrorDev]

Not sure if it's outside the scope of this website, but there are some useful external tools like

• cargo-nextest - [website]
• cross

[epage]

I'd add "release automation". I list several tools in this space on cargo release's README

[epage]

Maybe also cargo expand and either cargo bloat or cargo llvm-lines.

Probably cargo-edit as well though cargo rm will be in 1.66, there is still cargo upgrade.

[nicoburns]

Tooling section added. Leaving this issue open for people to add more tool suggestions.

[epage]

Thanks!

In looking at it, the docs.rs links seems less useful.

[nicoburns]

Hmm... yes, good point. I've added custom links (mostly to github repos) specifically to this section. This automatically suppresses the doc links.

[CosmicHorrorDev]

Other cargo plugins I have installed that I also see recommended often

• cargo-audit / cargo-deny
• cargo-bloat
• cargo-flamegraph
• cargo-outdated (already included)
• cargo-udeps

[djc]

I would probably not mention cargo-outdated, which has limited utility once you use cargo upgrade (which is included in cargo-edit).

I think cargo-deny is great and probably merits a mention. It encompasses cargo-audit and could probably also replace cargo-license (which I'm not that familiar with).

[pacak]

cargo-outdated would repeatedly pull the same git repo over and over again if you have git dependencies (slow) and would crash without producing any useful output if it can't figure out how to upgrade something.

cargo-upgrades is much better in that respect - no redundant pulls, no crashes.

cargo upgrade is pretty meh since it mixes both semver compatible and semver incompatible changes - you usually want to upgrade semver incompatible stuff one by one.

[pacak]

cargo-show-asm might be useful somewhere around "Performance" part of the tooling section.

[djc]

cargo upgrade is pretty meh since it mixes both semver compatible and semver incompatible changes - you usually want to upgrade semver incompatible stuff one by one.

The current version does actually offer options for this -- I use cargo upgrade --compatible=ignore --incompatible=allow, for example.

[nicoburns]

I would probably not mention cargo-outdated, which has limited utility once you use cargo upgrade

My workflow is similar to pacak's: I upgrade semver compatible versions using a simple command (cargo update can do this natively: no need for a separate tool). For major/minor changes I usually want a list of available versions which I can selectively upgrade. I want to upgrade a single library at a time, fix any breakage, then do the next one. For this I need a list of available updates. A command that just upgrades everything isn't very useful (although a command that upgraded a single library to the latest version would be).

[epage]

cargo upgrade --dry-run will report a report similar to cargo outdated. We are wanting to settle on a design to stablize in cargo and figured the table would be directly helpful and could allow reducing the need for extra commands (similarly, cargo add can act as a minimal feature editor).

A command that just upgrades everything isn't very useful (although a command that upgraded a single library to the latest version would be).

cargo upgrade can do that with cargo upgrade --package clap (or cargo upgrade -p clap for short) which works well when combined with --dry-run for seeing what upgrade options are available. I should check with the cargo team if there is a reason against adding the common dry-run short of -n to existing cargo commands which would make more more comfortable adding it to cargo upgrade.

[pacak]

The current version does actually offer options for this -- I use cargo upgrade --compatible=ignore --incompatible=allow, for example.

New behavior seems better, but it's about 5 times slower compared cargo upgrades - 1 vs 5 seconds.

The way it outputs things though is still worse compared to cargo upgrades:

• things are going to stderr - a surprising behavior when you have to redirect the output or use it with less
• things are formatted in blocks with aligned columns which looks neat if you have only one package but is just a visual mess when you have a bunch of crates in a workspace
• uses colors in not a good way with no obvious way to disable them
• summary at the end contains "unchanged" crates - in my case that's a lot of crates - not very useful, plus it includes crates from the workspace itself which is even more strange. This final blob of text forces you to use less/redirect...

[epage]

@pacak mind providing that feedback on https://internals.rust-lang.org/t/feedback-on-cargo-upgrade-to-prepare-it-for-merging/17101?

EDIT: Ideally with sample output

[pacak]

mind providing that feedback on

Sure. Is there a place on github with this merge request?

Anyway, I'll read though that, but will probably take a day or two.

[epage]

The above internals thread that I linked is where we are collecting feedback and discussing the design on its path towards being merged into cargo.

[nicoburns]

Closing this now. Any additional suggestions can be submitted via a new issue :)