Happy to announce that version 0.1.1 of ArgMacros is now in the Julia registry. ArgMacros offers a few new advantages for argument parsing:
All arguments are stored directly as statically typed local variables via macros
Convenient syntax for quickly defining arguments, help, and tests
Performant parsing; directly building the necessary parsing code in your script via macros, not building any intermediate data structures to hold processed values
Minimal impact on load times
Would appreciate any feedback if you use this package and find it useful or have issues. Targeting multiple value arguments and an untyped mode for a version 1 release.
From a quick glance at the documentation, it seems that I can only use String, Symbol and subtypes of Number. Do you plan adding support for other/custom types?
ArgParse has a somewhat richer set of features, with the tradeoff of higher load times, slower parsing, no localization/static typing of variables (which requires additional effort if you want to do those things).
It also has considerably different syntax, which is a plus or minus depending on your preference. ArgParse is also a more mature library, which has certainly had more real-world testing up to this point, while ArgMacros is v0.1.1 and newly released.
All of that being said, I think in most use cases, script writers will prefer the ease of use and speed of this module compared to ArgParse.
As of now, the types that can be interpreted are recommended to be limited to those specified, however you can try others. Technically it supports anything that has a direct constructor from a String, with special cases for using parse instead on Number types. Complex support is broken now too, but this will be fixed soon. I guess I don’t see a situation where many other types can be read in directly from the command-line, but I will update the documentation to mention the constructor from String requirement so that people can use it to read in any custom types they define that constructor for.
Another consideration here, even with just adding Complex support, is how much you want the user to have to mimic Julia syntax when entering arguments. With the currently recommended types, there is no special syntax for the user to consider when entering the arguments; a float is a float, an int is an int, a string/symbol is just text.