Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More robust argument parsing on command line tools #381

Open
jessemapel opened this issue Apr 25, 2022 · 3 comments
Open

More robust argument parsing on command line tools #381

jessemapel opened this issue Apr 25, 2022 · 3 comments

Comments

@jessemapel
Copy link
Contributor

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

See #380 and #377 for more context

@oleg-alexandrov
Copy link
Collaborator

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.

@jessemapel
Copy link
Contributor Author

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.

@oleg-alexandrov
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants