Re: Yet another command line DSL

[sirgazil <sirgazil@zoho.com>]

On 28/12/17 16:50, Amirouche Boubekki wrote:
> Héllo all,
> 
> 
> I had to scratch an itch about command line interfaces again.
> 
> In Python, I use http://docopt.org/ but it's pain (even if less
> painful that argparse and click) because you have to manually
> dispatch to the correct function based on a single dictionary
> to the correct function.
> 
> Long story short, I made a replacement for that, that should improve
> the developper experience in guile.
> 
> Here is an ascii video of the thing:
> 
>     https://asciinema.org/a/VpSS5YTfEuKgAg0J6zwR9ZBxW
> 
> It's guix related so you might be able to relate to it.
> 
> At the end of the video the code and attached to this mail.
> 
> Basically, the idea is to create a nested alist ie. a tree,
> where leafs are procedures as specification for the cli.
> 
> It looks like that:
> 
> (define xote
>    `((package
>       (install ,package-install)
>       (search ,package-search))
>      (system
>       (init ,system-init)
>       (reconfigure ,system-reconfigure)
>       (generation
>        (switch ,system-generation-switch)
>        (list ,system-generation-list)))))
> 
> I find it very pleasant to read.
> 
> When the user type a command like:
> 
>    xote package install guile@2.2.3
> 
> The the program will walk the spec and the program arguments
> at the same time to look for a possible match. When it finds
> a match it checks whether the user wants help otherwise it
> executes the command with the rest of the program arguments
> that are not matched. In the above example ``'("guile@2.2.3")''
> is passed as an arugment of the ``package-install'' procedure.
> 
> What I plan to do next, is to provide a generic function that
> will look for --optional=arguments in the rest and outputs
> two lists:
> 
> - an alist of --optional=arguments or short options like -K
> 
> - again, the rest of the arguments that were not parsed as
>    short or long options.
> 
> This simple and generic implementation of arguments will require
> the developer using this tool to validate the options if he really
> wants. And will allow him to use his favorite cli tool for short
> options...
> 
> The end result is that we have the best of both world, pleasant
> interface that organize its subcommands by topic and the liberty
> to use a powerful other framework to parse optional flags.
> 
> I find this approach clean and sleak.
> 
> 
> WDYT?

Thanks, Amirouche! I actually need this :) Nice :)