CLI WG newsletter #2

[killercup]

Welcome to the second issue of the CLI working group newsletter!

The CLI WG’s goal is to make writing cross-platform, well-tested, modern command line applications in Rust frictionless.

Survey results

In our last issue we asked you to participate in a small survey to help us gauge what areas to focus on. We are very pleased to say that we have received over 1000 replies! Thank you all so much! Your replies were super helpful, and a lot of them were very detailed and gave us invaluable insights.

You can find our summary of the survey results here. We’ll also make sure to link to the results when opening new issues, and add quotes from the survey as motivation for issues to work on.

What we have been doing

• There were two CLI sessions at the Rust All Hands in Berlin. You can find meeting notes here.
  1. The first meeting was about the survey results (see above)
  2. The second meeting was about distribution.
     • We talked with people involved in some packaging efforts
     • @ag_dubs, @josh, and @spacekookie wrote an RFC to Make cargo install extensible
     • This RFC builds on the metabuild RFC (semantic build scripts for Cargo) – which was merged in the meantime!
• @spacekookie created a repository for the confy crate (after getting the crate name from the previous owner)
• @spacekookie also started the thunder crate, which is a proc-macro to generate clap-based CLIs with subcommands using attributes on impl block
• @epage opened a pull request to refactor how assert_cli works

Join in!

We keep track of open discussion in this repo and you are very welcome to join us on Gitter to chat about what you want

---

This newsletter will be released regularly. If you want to get something mentioned, leave a comment on this issue.

[Keats]

Very good read!

Clap v3 and some kind of blessed term color crate would already go a long way to make starting a CLI more ergonomic.

Regarding configuration, one of my project is using TOML with some flags (https://github.com/Keats/gutenberg) and another one where it’s coming from flags/var env (https://github.com/Keats/dbmigrate) and I don’t think a lib approach would really make sense. One of my issue being there can be different levels of config depending on the environment as well (dev/staging/prod etc) and TOML is not suited for that. I started a WIP of an alternative language similar to the one from Nginx: SCL (Better ergonomics of merging various levels of configs) but with env var/include support built-in. I’m not suggesting to switch from TOML (even though I don’t like TOML) but it could be an alternative way to explore.

Something that could be nice is to have cargo allow splitting a crate in a workspace locally but upload it to crates.io as a single crate. I split gutenberg in lots of subcrates to not die of old age while compiling but II can’t be arsed to upload all the useful-only-to-me crates to crates.io to make it work for cargo install

Edit: having the link for SCL would have been smart! https://github.com/Keats/scl

[epage]

I assume the incremental compilation improvements have not worked out in your cases?

I remember seeing an RFC for allowing path dependencies. Looks like its been postponed.

[Keats]

Even with incremental compilation enabled, it still was taking 30+ seconds on each change. cargo check was fast enough but I wanted to run tests often. The code is quite a bit bigger now but I can make changes and run isolated tests in 3-4s depending on the subcrate.