Up until now, we've had multiple binaries (`sp-codegen` `sp-docgen` etc.) which each have specific functionality and CLI arguments. This has been good up until now, but I feel now is a good time to open a discussion on if it's what we want long-term. There are three approaches as I see it - the first is to continue to have multiple binaries, the second is to switch to a single binary with a git-style UI (i.e. `subplot codegen ...` `subplot docgen ...` with the option of `subplot-codegen ...` being the same as `subplot codegen ...`), and the third is to go for a purely multi-call binary where we have a single binary `subplot` but which looks at _arg0_ to decide how to run, and we use symlinks for `sp-docgen` et al. --- # Multi-binary approach * Pros * No change from now * Easy to support for things like the pandoc filter binary * Each binary only needs the CLI args it actually uses * Cons * Longer compile time (each binary is linked independently) * Takes more disk space in the end * Each binary has independent CLI which can lead to inconsistency # Multi-call binary approach * Pros * Very little change in usage vs. current multi-binary approach * Cons * Needs symlinks/hardlinks setting up after build * Needs code writing to support different _arg0_ values * Doesn't `cargo install` very easily. # Git-style UI * Pros * Unified CLI parsing means less chance of confusion between kinds of operation * Sort of what people are used to these days * Can still support _arg0_ switching for things like `sp-filter` if absolutely needed * `cargo install` very easily indeed * Cons * The most work to set up * Will require everyone who currently uses subplot to switch to the new CLI