guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Yet another command line DSL


From: Amirouche Boubekki
Subject: Yet another command line DSL
Date: Thu, 28 Dec 2017 22:50:56 +0100
User-agent: Roundcube Webmail/1.1.2

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 address@hidden

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 ``'("address@hidden")''
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?

Attachment: izicli.scm
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]