3 ms·

It seems like docopt was trendy for a while which always surprised me. The idea of specifying your CLI in an incompletely defined DSL embedded in a string alway

by epage 5y ago

It seems like docopt was trendy for a while which always surprised me. The idea of specifying your CLI in an incompletely defined DSL embedded in a string always confused me both because of the brittleness and because there is stuff you just can't express (like types). In Python, I was always skeptical of click which later took the attention though I think using StructOpt [0] in Rust has cured me of that to a degree though I much prefer field attributes over stacking function attributes per parameter (or Typer's form of parameter attributes). I'd probably still stick with argparse anyways because most of my Python scripts are built without dependencies (weird build systems or being one step above bash scripts). [0] https://docs.rs/structopt/latest/structopt/ https://docs.rs/structopt/latest/structopt/

smitty1e 5y ago
Speaking of Click: "Docopt, and many tools like it, are cool in how they work, but very few of these tools deal with nesting of commands and composability in a way like Click. To the best of the developer’s knowledge, Click is the first Python library that aims to create a level of composability of applications that goes beyond what the system itself supports. Docopt, for instance, acts by parsing your help pages and then parsing according to those rules. The side effect of this is that docopt is quite rigid in how it handles the command line interface. The upside of docopt is that it gives you strong control over your help page; the downside is that due to this it cannot rewrap your output for the current terminal width, and it makes translations hard. On top of that, docopt is restricted to basic parsing. It does not handle argument dispatching and callback invocation or types. This means there is a lot of code that needs to be written in addition to the basic help page to handle the parsing results. Most of all, however, it makes composability hard. While docopt does support dispatching to subcommands, it, for instance, does not directly support any kind of automatic subcommand enumeration based on what’s available or it does not enforce subcommands to work in a consistent way." https://click.palletsprojects.com/en/8.0.x/why/#why-not-docopt-etc https://click.palletsprojects.com/en/8.0.x/why/#why-not-doco...
- cb321 5y ago
  I think plac and argh in the Python space pre-dated Click by a long time and had many similar features. I'm not sure if they had everything the Click author exactly wanted, but they do seem like strong prior related work.
- michaelcampbell 5y ago
  > Most of all, however, it makes composability hard. I see this argument a lot as if it's self evident. Using X makes Y hard. Ok, what if you don't need Y?
  - dragonwriter 5y ago
    > Using X makes Y hard. Ok, what if you don't need Y? Then knock yourself out using X. It's an argument about the purpose of the alternative and what it is intended to be useful for. Assuming that it is valid, it tells you both for what purposes you might want to use the alternative and for what purposes you might not want to bother. Z improves on X for Y is fairly explicitly not an argument that Z is superior to X for all purposes.

by epage 5y ago

smitty1e 5y ago

Speaking of Click: "Docopt, and many tools like it, are cool in how they work, but very few of these tools deal with nesting of commands and composability in a way like Click. To the best of the developer’s knowledge, Click is the first Python library that aims to create a level of composability of applications that goes beyond what the system itself supports. Docopt, for instance, acts by parsing your help pages and then parsing according to those rules. The side effect of this is that docopt is quite rigid in how it handles the command line interface. The upside of docopt is that it gives you strong control over your help page; the downside is that due to this it cannot rewrap your output for the current terminal width, and it makes translations hard. On top of that, docopt is restricted to basic parsing. It does not handle argument dispatching and callback invocation or types. This means there is a lot of code that needs to be written in addition to the basic help page to handle the parsing results. Most of all, however, it makes composability hard. While docopt does support dispatching to subcommands, it, for instance, does not directly support any kind of automatic subcommand enumeration based on what’s available or it does not enforce subcommands to work in a consistent way." https://click.palletsprojects.com/en/8.0.x/why/#why-not-docopt-etc https://click.palletsprojects.com/en/8.0.x/why/#why-not-doco...

cb321 5y ago
I think plac and argh in the Python space pre-dated Click by a long time and had many similar features. I'm not sure if they had everything the Click author exactly wanted, but they do seem like strong prior related work.
michaelcampbell 5y ago
> Most of all, however, it makes composability hard. I see this argument a lot as if it's self evident. Using X makes Y hard. Ok, what if you don't need Y?
- dragonwriter 5y ago
  > Using X makes Y hard. Ok, what if you don't need Y? Then knock yourself out using X. It's an argument about the purpose of the alternative and what it is intended to be useful for. Assuming that it is valid, it tells you both for what purposes you might want to use the alternative and for what purposes you might not want to bother. Z improves on X for Y is fairly explicitly not an argument that Z is superior to X for all purposes.