aobatact / clap-serde Goto Github PK

• case tests

  • snake-case
  • pascal-case
  • kebab-case

• Command flag test

• Arg flag test

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.

It looks like there isn't global settings support. Is this intentional?

I see #[serde(rename_all = "lowercase")] is applied. I think kebab-case or snake_case would be more idomatic.

Env variables are behind an extra clap feature flag and I'm assuming users would be interested

If #4 is rejected, maybe support derefing to the inner types. Doing so, you could probably drop the Wrapper suffixes.

Provide some way to deserialize from yaml

Both user documentation and machine (schema) will help users to know how to use this.

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.

Once #22 lands, we can create a doc generator by creating custom serializer to generate document to solve #10 .

This make it possible to use a config file as localization

Something like load(impl serde::Serializer) -> clap::App

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

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.

Do we need OsStr support?

flow considered

1. use config of CLI defined in TOML/YAML file
2. parse command line parameters
3. export CONSTANT_CASE ENV vars.
4. so any script/app running after can access to ENV vars parsed

https://discourse.nixos.org/t/nix-bash-maxi-declaratively-configured-cli-args-to-env-vars-tool/37735

Run example.sh --some-par=42:

SOME_PAR=13 clap2env clap-config.toml $@

echo $SOME_PAR

will give

42

This was requested in clap, see clap-rs/clap#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)

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

TODO

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

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