Hi all — I'm hoping to gather some feedback about how to evolve the CLI of my program.
I lead the development of tectonic, a modernized, self-contained TeX compiler. Right now, we distribute a tectonic
binary that has an interface kind of like rustc
: you give it a source file as an input, pass it a bunch of options, and get an output file. But I want evolve the to be CLI more like cargo
: have the build options declared in a Tectonic.toml
metafile, so that the user just has to run tectonic build
or some such thing.
This raises the question: how should I evolve the CLI? I've focused on two main options:
- Take the Rust approach: add a new CLI program with a different name, and have it invoke
tectonic
under the hood. Pros: least breakage. Cons: permanent maintenance overhead from having thecargo
/rustc
aspects in different executables; training overhead to teach people to use the new program. - Keep the two aspects in a single executable and migrate the CLI. One potential plan:
- Add an optional flag to indicate current the "rustc"-type CLI:
tectonic -Y [rustc-style]
- Add a required flag to indicate the the new "cargo"-type CLI:
tectonic -X [cargo-style]
- Start telling people to migrate to the
-X
style CLI - At some point, swap the default CLI interpretation:
-X
is optional,-Y
is required - Eventually get rid of the
-Y
CLI altogether, probably. (With a good enough "cargo"-style CLI, I don't think it adds any value.)
- Add an optional flag to indicate current the "rustc"-type CLI:
You could imagine a few variations on these basic ideas. I think the basic tradeoff is that keeping things in a single executable seems like a big win for future maintenance, but requires some kind of migration process.
But maybe I'm not thinking creatively enough. Anyone have any ideas about how to get the best of both worlds? Or maybe some technical reasons that the "rustc" and "cargo" functionalities split into separate executables despite the added complexity?