More robust argument parsing on command line tools
Opened this issue · 3 comments
We can't use the standard getopts header because it's not available on windows. Is there some other argument parsing tool we can use for our scripts? Ideally it will be:
- light-weight. Header only would be best
- Usable for both unix and windows
- Not inhibited by restrictive licensing, think GPL
- Available on Conda
I guess the question here is if we need a command line parser which is general enough to handle any future parsing needs we could ever think of, or if the little parser I added is not good enough for the job it meant for. About the latter, I am not so sure.
The parser I put in is able to handle anything the user throws at it, and either parse the inputs correctly if those are as documented, or error out with a usage message if the user did not invoke the tool as expected.
Hence I view this issue as something nice to have rather than something required in order for existing software to function as intended.
I agree this is mostly a nice to have if we want to build out our command line toolset. It's something that is lacking with our CSM packages at the moment, see DOI-USGS/ale#437
I would like to unify the user focused tools into a single location if possible. Right now things are scattered all over the place between ALE, USGSCSM, Knoten, and even ISIS.
In my experience the boost program options and Google's GFlags are very robust and freely available. ISIS already depends on Boost, so if in the future we surely need a robust parser, we could go with that, maybe, rather than bringing yet another dependency.
I found getopts.h to be somewhat awkward to use, and unlike boost, it can't print a help message describing each option, which is a nice functionality both for the user and also for the developer as it keeps each option's explanation where the option is defined.
I would like to unify the user focused tools into a single location if possible. Right now things are scattered all over the place between ALE, USGSCSM, Knoten, and even ISIS.
The Python tools need a Python run-time of a specific version installed with them, which I think is a little annoying, but I guess the user would not mind if using conda. So Ross's little tool could be added as officially supported under usgscsm as it creates a CSM model.
If the knoten tools depend on GDAL likely we can't bring them in since then usgscsm would not play nice with isis itself so maybe they are best left where they are.