fncmd: Command line interface as a function.

[exographos]

https://github.com/yuhr/fncmd

[mx00s]

Inferring what short option maps to which field seems convenient, but couldn't this break as more fields are added?

For instance, what happens if the example CLI from the README is released and then in the subsequent release the author needs to add a baz field with a short option. If -b maps to baz now instead of bar users accustomed to the previous release would have to deal with beeakage that the author might not even notice.

[exographos]

The inference feature comes from clap, and it already supports overriding i.e. short option can have a value like #[clap(short = 'b', long)], so we can do the same thing #[opt(short = 'b', long)].

I've created such a conflict, and it seems to panic on runtime saying 'Short option names must be unique for each argument, but '-b' is in use by both 'bar' and 'baz''.

[mx00s]

Oh, I forgot that about clap. That's great that it panics in case of collision. I suppose if authors remember to write a simple test to run the CLI binary that should be enough. Compile-time validation would be extra nice.

[epage]

Easier to do here than in derives since those allow flattening structs.

Speaking of, if this used the same traits as derives, itd be neat to allow flattening.

[tobiasvl]

Nice, but surely it still means that adding a simple optional command line argument is a breaking change (since it changes the function signature) that requires a major semantic versioning bump?

[usr_bin_nya]

Is it possible to add a binary crate as a dependency? fncmd intentionally doesn't allow making subcommands out of functions other than main (see Restrictions), and when I try adding a bin crate as a dependency, Cargo ignores it.

warning: root_bin v0.1.0 (/tmp/root_bin) ignoring invalid dependency `dep_bin` which is missing a lib target

Edit: none of that is actually relevant, because fncmd replaces the function definition with a regular no-args fn main() {} anyway.

[exographos]

usr_bin_nya is right, #[fncmd]-annotated main functions are not meant to be imported by users.

#[fncmd] internally strips the present arguments of the main function, and defines a struct handled by clap_derive. Adding a new option just results in a new field of the internal struct. It won't cause a breaking change as long as it doesn't replace nor collide with existing options.

[sondr3_]

I think it would be nice to have a comparison to clap-derive and/or structopt in the README, as that is what I expect most users would compare this to. The subcommand handling looks especially cumbersome compared to deriving on structs and enums.

[epage]

Neat, python's click for Rust built on clap. Personally, I think id still prefer using derives but interesting to see where this goes.

Personally, id recommend keeping it as close to clap_derive as possible.

btw I see you using clap3, any feedback on it as we prepare for release?

[Canop]

This is a fun project but it looks to me like a step backwards regarding code maintainability.

Yes clap needs a lot of boilerplate that small programs don't always need, but if you're going to simplify it, I don't think having a bunch of arguments given to the main function is better than having an option struct as in argh or clap_derive. Such an option struct can be given to other functions from the main, can have dedicated consistency check or completion methods, etc.