This is where I've disappeared to over the last 3 months, trying to wrap up a years-old experiment that has been "almost done" for these last 3 months, with use case after use case building up encouraging me to finish this up rather than my regularly scheduled Cargo work.

The tl;dr is to think of this as finding right abstractions to stabilize parts of cargo_test_support and cargo nextest.

Quick links

• docs.rs
• crates.io
• repo

I would like to introduce you to winnow, a fork of the venerable nom parser combinator library. For those that want to skip all the details, you can checkout the documentation and the migration guide and changelog.

I would link to the docs but docs.rs seems to be backed up this morning.

This release builds on work done in the 3.x releases and can be worth catching up on them:

• The 3.1 release
• The 3.2 release
• Or the v3 CHANGELOG.md for the over 50 patch releases since 3.0.0

To put all of this work into numbers:

(see Methodology for more details)

Aside: Yes, those clap v2 -> v3 numbers are not good.

For Builder API Surface, it is understandable when you consider we mostly didn't remove functionality in v3 but deprecated it, removing it in v4.

Lines of Code is mostly accounted for with the merge of structopt into clap as clap_derive. We continued to have significant growth after that as we continued to develop replacement features for functionality in clap. These more general solutions take up more lines though not more code size.

For code size and runtime, one factor is that things fell through the cracks during clap v3's development. clap's development went dark for an extended period of time and went through several maintainers. This isn't to say one of the maintainers is at fault but that things get lost in hand offs. Towards the end, we double-downed on just getting out what we had and hadn't looked to see how we compared to v2.

For code size, it looks like it was a lot of small changes that added up, like changing a VecMap to a BTreeMap.

For runtime, it seems to mostly be a single feature that caused it which was removed in v4 [5].

Our plan is to give about a week window between the release-candidate and the official release to allow for collecting and processing feedback.

With clap 3.1, we discussed the need for a more open, extensible API and clap 3.2 represents one step in that direction. With two new builder API concepts, we are able to deprecate the following concepts:

• Arg::allow_invalid_utf8
• Arg::validator, Arg::validator_os
• Arg::forbid_empty_values
• Arg::possible_values
• Arg::max_occurrences
• Arg::multiple_occurrences
• Command::args_override_self
• AppSettings::NoAutoVersion
• AppSettings::NoHelpVersion

clap 3.0 was in development for 4 years and though we saw comparisons to Half-life 3 in response to the release, we also saw people who cited the long gaps between breaking releases as a motivation for using it. For clap to stay relevant we feel we need to avoid the stagnation of long release cycles while keeping things smooth for the users where clap is already "good enough". The v3.1 release is a major step in trying to strike that balance.

This came up in a recent discussion focused on the relevant importance of setting the minimum patch version for a dependency. Some crates go so far as to never bump their minor version, like serde.

Some major milestones along the way:

• Jan 24, 2018: The first commit in the v3-dev branch
• Aug 30, 2019: StructOpt 0.3 is released with better clap integration
• May 03, 2021: v3.0.0-beta.1 is released
• Dec 08, 2021: 3.0.0-rc.0 is released
• Dec 31, 2021: 3.0.0 is released

Thanks to:

• kbknapp, pksunkara, dpc, killercup, spacekookie, yosh, ldm0, and any other maintainers or contributors along the way
• Our users, especially those providing feedback on beta and release-candidates
• Embark, Sentry, repi, and many other sponsors
• My employer, Futurewei, for giving me the opportunity to help wrap up clap 3.0

toml_edit is a format preserving TOML crate, allowing users to modify .toml files.

Before:

After:

Target:

As part of improving the learnability of Rust, I propose:

• The .crs file subset of cargo-script be brought into cargo
• We support converting .crs to full cargo projects with cargo init --from <script>.crs
• We collaborate on an ergonomics-focused standard-library-alternative, like eztd

Seeing the performance numbers, I was curious what the experience was like with the different techniques compared in the followup and how the performance worked out in a real world application.

liquid-rust is a rust re-implementation of the liquid template engine made popular by the jekyll static site generator.

• Rust in 2020, one more thing
• Thoughts on Error Handling in Rust
• Error Handling Survey