Hacker News new | past | comments | ask | show | jobs | submit login
Docli – A declarative language for command-line interfaces in Go (docli.dev)
131 points by celicoo 32 days ago | hide | past | web | favorite | 65 comments

I used to love doctopt, but with usage your realise:

- i18n is made hard

- syntax errors are not caught by tooling

- you don't get automatic args checking or env var override

Eventually, a well made programmative API is better.

I used docopt in production for years, before switching off of it.

My main issues were that the author of docopt doesn't know anything about language grammars & parsing. That's fine — we all start somewhere. But he insists that defining a grammar (and having a rational parser) aren't useful or even possible! If, instead, there were a normative spec (and this requires only the slightest change to edge-cases that aren't tested by his test-suite, anyways), then it'd be possible to really roll out a much more robust docopt than what currently occurs.

With a grammar you'd be able to roll out AST=>AST transforms, and update the parsing strategy of the command lines, i.e., portability between CLI flavors between new/old style POSIX, Windows, etc. You'd have the ability to do i18n, you could catch errors both in the docopt spec of your parser, and in the parsing of the command line options, etc.

I've started with a fork of Docopt, but then I realized the exact same thing - the maintainers didn't use the best parsing practices, so I've just deleted the fork and started Docli. If you follow the tutorial you will see that you can print the AST produced by Docli's parser :D.

So did you end up making something better? I’ve been using docopt for years but I’ll gladly consider switching to a better alternative.

May I suggest you give https://github.com/jawher/mow.cli a look/try ?

Disclaimer: I'm the author of mow.cli ;)

All of my publicly available thoughts are here: https://github.com/jaroslov/docoptc

Totally! I love the idea of Docopt, but I don't like the implementation - that was the perfect excuse to start Docli (Although some of these points were not YET addressed).

>- i18n is made hard

It's also mostly redundant. I'd expect CLI users to be able to parse flags and --help messages in english.

And I'm not saying it as a native english speaker -- which I'm not. Without english knowledge you can't parse 99% of existing, never to be i18n standard UNIX commands, flags, and manpages.

> Without english knowledge you can't parse 99% of existing, never to be i18n standard UNIX commands, flags, and manpages.

That makes me sad.

That makes me happy. I'm all for national languages, ethnic nuances etc (I'm not English-native-speaker myself), great spell checkers, voice recognition, fonts, etc for all languages.

But for text work (writing, reading, etc).

Not on my fucking programming languages (like bizarro foreign variable names in source code), and ideally, not on my CLI either.

Let's have a common universal language in our domain.

Doctors get to use latin names and common terms for tons of medical staff whatever their country. Pilots get to speak english with every control tower all around the world.

Computer work should have some of that too.

There's a difference between having source code and CLI commands in a hodge-podge of languages and not having translations of man pages.

I'm not sure if 99% is accurate - unless you intentionally include internal tooling ("standard UNIX commands" implies not).

Now, if you mean "actual UNIX", I'm not sure - but at least gnu is pretty widely translated. Not sure where the bsds stand on this.

> which I'm not. Without english knowledge you can't parse 99% of existing, never to be i18n standard UNIX commands, flags, and manpages.

Most of the standard GNU commands are translated, at least I can't think of any which is not.

This is a Go library that parses a usage string into an AST.

"Docli" makes it sound like a generic documentation generator for CLIs.

IMO name should make it clear it is Go-only. Something like "GoastArgs: a Go library that parses a usage string/CLI args into an AST"

I am not a Go user so I can't speak about Go specifically, but I feel like including the name of the language in the library name is in general an anti-pattern, since generally when you look for a library to do something in language A, you aren't going to get results using language B anyway.

Thanks for the feedback umvi. I will be working on making it clear that Docli is a Go library.

But, for the love of God, please don't put the word "Go" in the name :D

Exactly! Thank you for clarifying that. The documentation still needs some improvements, and this is one of them.

Thanks, it's very disappointing when a comment describes the product better than the official webpage.

Not that unusual really. Whenever you hear about new stuff, chances are it's better to look it up on Wikipedia first.

Docli doesn't seem to have a Wikipedia article yet.

Not unusual. But still disappointing.

I still feel that cobra and docopt are ungoish despite the author of cobra getting hired on. There's simply too much magic to both of them. I would much rather they improve flags, which is what I use. It really doesn't take that much with flags to add subcommands, etc, but it could be made better.

Can you elaborate on what makes cobra ungoish? I had built a CLI using it without prior knowledge of Go (but with a background in scripting languages and a some C#) and it seemed pretty straightforward.

The only issue that I can tell was that you can possibly create errors that the compiler can miss, but it's been pretty solid otherwise.

Cobra is very much a kitchen sink approach with a lot of gen. I'd rather have less dependency and write just using the stdlib without the kitchen sink, which is more goish.

That makes a lot of sense.

I guess the parallel for me would be using Rack as opposed to Rails for Ruby.

Thanks for responding!

I use github.com/urfave/cli, but I almost always end up wrapping it with my own declarative framework. Gradually said framework is becoming more general purpose and suitable for general use, at which point I'll probably open source it and hopefully it will make someone's life better.

For servers I prefer using: https://github.com/alecthomas/kingpin, allows you to really nicely expand based on main arguments with flags. Also, setting defaults is a joy.

For CLIs - https://github.com/spf13/cobra.

However, will definitely try out Docli whenever I start building something new :)

Seems like Cobra is pretty well established in this space - https://github.com/spf13/cobra

Tho admittedly it works in reverse; it generates the doc/help info rather than parsing it into an AST. It addresses the “boilerplate” issue with code gen as well, but it has a CLI to generate code that’s pretty powerful.

For instance, how does docli handle subcommands? How about global vs command specific flags? For any case beyond the basic single command CLI, it seems like there would need to be all sorts of magic and non-obvious formatting requirements on the doc string.

Hey! I've opened an issue to discuss about the subcommands feature: https://github.com/celicoo/docli/issues/10

I would love to know your opinion about it.

Hey thanatos_dem

Right now Docli can't handle those scenarios, but it will on the next big release - which it might take a while because it's not trivial to add those features and keep the API simple.

Anyone have a recommendation for Node.js? I've been extremely frustrated with commander [1].

[1] https://www.npmjs.com/package/commander

I can second this recommendation – Oclif[0] is an absolute pleasure to use. I'd even encourage developers who aren't at a "full-stack Node.js shop" to give it a shot.

I'm particularly impressed with the bash and zsh autocomplete support. I was delighted when I finished setting it up and everything worked perfectly on the first try.

[0]: https://oclif.io/

HN had something on this a few months back, "12 Factor CLI Apps":


There are lots of different approaches to defining the arguments and options.

* You can build up a structure programmatically to define the arguments, as in commander, and then the usage and shape of the parsed result are implied.

* You can provide the usage, as in docopt, and then the structure to define the args and shape of the parsed result are implied.

* Or you can take the approach I did in fncli, which is to provide the shape of parsed result, as a function signature, and let the structure to define the args and usage be implied.


This is possible because Javascript spec includes the function arguments as a string that can be parsed at run time.

Because you're using ES6 syntax, you don't have to learn a new syntax (unlike docli or docopt). And although there are limitations, I've found this approach to handle modest CLI needs with an absolute minimum of fuss.

You may want to try my markdown based CLI definition tool:


Generates help files, man pages, shell autocomplete for bash etc

Lots of folks seem to like Yargs: https://github.com/yargs/yargs

I really like that graphic for the website and README! Did you make it?

Thanks! It was a friend of mine. You can see more of his work at https://www.instagram.com/sutocreation

Prior art: http://docopt.org/

I suspect they were not unaware of Docopt:

> Docli is 100% inspired on docopt.

This looks awesome, thanks for mentioning it!

Not really a fan of this approach. I don't like the duality between the help text and the struct it gets bound to - much prefer the approach of generating the help text from a struct.

https://github.com/jessevdk/go-flags is my favourite option; it's lightweight but amazingly featureful, and I much prefer the declarative approach to a programmatic one like the standard library flags package

Their example here confuse me:


`workspace` isn't a boolean flag. So it isn't clear from that example how - or even if - docli can work with more complex conditional arguments.

Is someone with any familiarity with this project able to advise how you'd handle that in docli?

All the variables in in the `Commands` and `AllOtherCommands` are bools.

In Go you can do `a, b, c bool` and they'll all be of type bool.

Yeah I got that. My point is that ‘workspace’ isn’t a Boolean flag in terraform. It requires additional flags to function, eg

  terraform workspace new granra
‘workspace’ is effectively the CLI flags equivalent of a submenu.

Oh I see. It looks like docli sets the flag as true if it was passed as a parameter to the program.

So you do:

var terraform Terraform


if terraform.Workspace {

  // do workspace stuff

I think.

EDIT: I don't know how hackernews formatting works :/

That seems really messy to be honest because you can’t then ensure flags are nested correctly.

I guess for simple purposes this is fine though.

For my purpose, go-flags was a great fit.


cobra is working pretty well for my needs: https://asciinema.org/a/192043

Nice to see a declarative approach, though. It certainly looks more natural. I'm certainly going to give it a try.

I really like the line art logo on the site, but it's 2.4 MB (avatar.png).

Might want to size it down and run it through TinyPNG. :)

Oh, I didn't notice how big it is! I will fix that as soon as possible. Thanks for the feedback.

It's a little strange that I had to open the tutorial to find out what language this is for.

I was going to guess Rust, but turns out it's Go.

Personally, I like Rust's a bit better:


edit: because it's type safe!

Wouldn't `gocli` be a better name then?

The solution here is clearly to write a new language named "do".

Does having a programming language name in a program name make the program better? I don't get it, sorry.

It certainly makes it a lot easier to understand what it's for...

I think it's a portmanteau of "doc" and "cli" - because it's a CLI options parser that is generated from documentation.

Hey, I'm really sorry about that! I'm still working on the details, but thank you for the feedback.

Please put the language it is intended for somewhere as close to the page top as possible. The world isn't all Go.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact