3 ms·

It's definitely a field that there's still need in. I recently started writing yet another argument parser, with all the knowledge of my prior attempts ... One

by o11c 2y ago

It's definitely a field that there's still need in. I recently started writing yet another argument parser, with all the knowledge of my prior attempts ... One thing I'm really starting to lean toward is the idea of using a bespoke data file to actually define the options, and having that generate the code. My key observation is that actually parsing the arguments is kind of secondary; the most important thing is to be able to generate good --help text (I've collected many samples and want to be flexible enough for them all). And for config files, to be able to generate a commented "default config" + merge with given command-line arguments. A GUI (or at least a JSON API for the web) for interactive selection, as well as tab-completion for the CLI, are also important. Now, I'm currently halfway through implementing a knockoff of the Unicode line-breaking algorithm so that people can translate my help text properly (for a program nobody else will probably ever use) ... I've basically forgotten the project that needed the argument parser. There are actually more sources than those you mentioned: * hard-coded defaults * config files * ENV=variables (may be a single TOOLNAME_OPTS variable or separate per-option variables) * --options and @files (may be nested, beware cycles) Beware of lists (default is port 8080, but I want 8000 and 8001 - wait, 8008 instead). And parsing also needs to handle more than just GNU style arguments. Single-dash long options are pretty common. Some tricky tools that most libraries can't handle: chmod, dd, more, ps, tar. For fused arguments, make sure your testsuite includes errors for `-a-b` and `-a-`.

IgorPartola 2y ago
Those are all great points. I do like the idea of a stand-alone file. Especially since then you could do code generation and if you care about doing type hints you now could. groper uses getopt built into the Python standard library as well as the ini file parser. This way there are no dependencies on external stuff. And it automatically generates help text with all the options and can automatically generate a sample config file with all the default options hard coded in the code. Those two things have made it invaluable for me when I used it extensively. I think adding environment variables to the mix would be a good idea. I am not sure what you mean by --options. By @files do you mean like what curl can do? If so I have always solved that by just doing something like --in or --file or just making the input file the last argument to the command. Lists are definitely tricky but if I recall correctly the version I put on GitHub allows you to specify the same option multiple times in order to get a list but I’m not sure that’s the cleanest way to do this. Possibly having custom option types that do splitting on a delimiter for something like port numbers could be good. In either case it’s good to know that this space still could use some work because that’ll be the motivation for me to dust off this project.

by o11c 2y ago

IgorPartola 2y ago

Those are all great points. I do like the idea of a stand-alone file. Especially since then you could do code generation and if you care about doing type hints you now could. groper uses getopt built into the Python standard library as well as the ini file parser. This way there are no dependencies on external stuff. And it automatically generates help text with all the options and can automatically generate a sample config file with all the default options hard coded in the code. Those two things have made it invaluable for me when I used it extensively. I think adding environment variables to the mix would be a good idea. I am not sure what you mean by --options. By @files do you mean like what curl can do? If so I have always solved that by just doing something like --in or --file or just making the input file the last argument to the command. Lists are definitely tricky but if I recall correctly the version I put on GitHub allows you to specify the same option multiple times in order to get a list but I’m not sure that’s the cleanest way to do this. Possibly having custom option types that do splitting on a delimiter for something like port numbers could be good. In either case it’s good to know that this space still could use some work because that’ll be the motivation for me to dust off this project.