7 ms·

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

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.

thechao 8y ago
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.
- cstejerean 8y ago
  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.
  - thechao 8y ago
    All of my publicly available thoughts are here: https://github.com/jaroslov/docoptc https://github.com/jaroslov/docoptc
  - jawher 8y ago
    May I suggest you give https://github.com/jawher/mow.cli https://github.com/jawher/mow.cli a look/try ? Disclaimer: I'm the author of mow.cli ;)
- celicoo 8y ago
  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.
coldtea 8y ago
>- 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.
- thayne 8y ago
  > Without english knowledge you can't parse 99% of existing, never to be i18n standard UNIX commands, flags, and manpages. That makes me sad.
  - coldtea 8y ago
    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.
    - thayne 8y ago
      There's a difference between having source code and CLI commands in a hodge-podge of languages and not having translations of man pages.
- e12e 8y ago
  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.
- realusername 8y ago
celicoo 8y ago
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).

thechao 8y ago

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.

cstejerean 8y ago
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.
- thechao 8y ago
  All of my publicly available thoughts are here: https://github.com/jaroslov/docoptc https://github.com/jaroslov/docoptc
- jawher 8y ago
  May I suggest you give https://github.com/jawher/mow.cli https://github.com/jawher/mow.cli a look/try ? Disclaimer: I'm the author of mow.cli ;)
celicoo 8y ago
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.

coldtea 8y ago

>- 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.

thayne 8y ago
> Without english knowledge you can't parse 99% of existing, never to be i18n standard UNIX commands, flags, and manpages. That makes me sad.
- coldtea 8y ago
  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.
  - thayne 8y ago
    There's a difference between having source code and CLI commands in a hodge-podge of languages and not having translations of man pages.
e12e 8y ago
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.
realusername 8y ago

celicoo 8y ago

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).