We are looking at dropping settings (see https://github.com/clap-rs/clap/issues/2717). Limiting your support for them would ease the transition when this happens (data model transitions are a hard thing to document appropriately)

If argument is set as required = false it seems to have no impact on argument rendered as an 'option'?

Only way I was able to add optional flags was to give them default_value and hide it from the --help with hide_default_value = true

I was testing with this toml:

name = "Service provider X"
version = "0.1"
author = "author"
about = "Commands to invoke service provider scripts."

[subcommands.node]
about = "Commands for managing server nodes" 
subcommand_required = true

[subcommands.node.subcommands.create]
about = "Create new server nodes"
arg_required_else_help = true

[subcommands.node.subcommands.create.args.name]
help = "Node name within the group"
forbid_empty_values = true

[subcommands.node.subcommands.create.args.group]
# default_value = "something"
# hide_default_value = true
short = "g"
long = "group"
help = "Node group name"

cmd: target/debug/test node create FirstArg --group GroupName

Above fails when --group is defined, works without the flag though. Starts working as expected with or without --group flag when default_value = "something" is uncommented.

Not a big issue, I was just curious. Thank you for your work on this, seems to be the only way to extend clap commands runtime.

Currently subcommands and args are objects in the data model. A lot of serialization sources consider the objects to have an undefined order but order of these is important. Rather than relying on implementation details of the serializers (and tools mucking with the raw data), I'd recommend switching these to arrays like in the old clap YAML support

name: myapp
version: "1.0"
author: Kevin K. <[email protected]>
about: Does awesome things
args:
    - config:
        short: c
        long: config
        value_name: FILE
        help: Sets a custom config file
        takes_value: true
    - INPUT:
        help: Sets the input file to use
        required: true
        index: 1
    - verbose:
        short: v
        multiple: true
        help: Sets the level of verbosity
subcommands:
    - test:
        about: controls testing features
        version: "1.3"
        author: Someone E. <[email protected]>
        args:
            - debug:
                short: d
                help: print debug information

The standard approach in the Rust ecosystem is to dual license

See https://rust-lang.github.io/api-guidelines/necessities.html#c-permissive

Doing so would make it easier to become a more semi-official clap project (even move into the clap org if you want). If interested, the earlier the done, the easier this is.

A lot of things have changed since clap 3.0. This crate needs to catch up.

TODO

• [x] App to Command
• [x] Add new flags for builder methods to Command
• [ ] Add new flags for builder methods to Arg
• [ ] Deprecations

Changes at ver 0.3

• Added more keys in App
• Added more keys in Arg
• Change the feature name of case settings.
• Add support to use the non snake_case key names.

App::help_heading applies to all future args being added. We expect to add more like this (App::next_display_order, `App::env_prefix).

The challenge will be to fit it in the data model.

This was requested in clap, see https://github.com/clap-rs/clap/issues/918

Other benefits

• Insights into clap building by allowing dumping before and after to see what changed
• Another way of providing insight into the derive API compared to cargo expand
• Hopefully help people detect some level of breaking changes (especially for the more magical derive API)