1. 15
  1.  

  2. 3

    I’ve used the following packages so far:

    docopts - This was marvelous when it came out. You wrote the specification for the CLI in the docstring, and docopts turned this into a working CLI for you

    click - This is much heavier than docopts, but is what I ended up using when writing a big program with many components (many subtools) and with options that could be fairly complex. Click is my goto tool for CLI building in Python

    I’m looking at where Python Fire sits in this line, and I think it sits in between. It has zero specification, in the sense that you don’t seem to have to explicitly write code for it (it uses introspection) and so is quick to get up and running. The prospect that the CLI will track your code automatically is very appealing.

    I suspect, however, that it will not do so well when you want a CLI in a particular way. Click for example allows you to nest commands, accept options that are members of a set (it will validate), handle stream inputs etc.

    1. 3

      From their described use of it, I think it might make more sense to think of it not really as a general-purpose CLI builder, though it technically does build a CLI, but as more of an FFI interface that generates bindings for shell scripts to call Python libraries (like the Python Imaging Library). Like most auto-generated FFI bindings, the quality of the result depends on some mixture of how good the original API was, and how well it translates to the calling language (in this case, the calling language being something like “CLI/shell conventions”).

    2. 1

      Looks vert nicely done

      1. 1

        I did something similar to docopts in Scala, which took away the need to learn yet another API and seems to be working well so far. Have a few CLI tools that use the lib at work.