refractor input parsing to be modular and assert correct inputs

[dbekaert]

@Askaholic discussed in other issue tickets to remove duplication on shared input arguments and their syntax between different programs.

In addition we discussed capturing driver errors early one. So, should we also implement a verification that input arguments are supplied correctly, directly after parsing?

• e.g. assumption on date order for seasonality?
• e.g. verifying dates and time are in correct and recognizable format

Lets discuss below.

[Askaholic]

I think a lot of the input validation can be done in the parsing stage directly by supplying parsing functions through the type parameter.

[dbekaert]

Would you recommend a single location for this for the parser and checks? https://github.com/dbekaert/RAiDER/blob/a3548e9f23d6280629f14bd2a15b75bcb5263f35/tools/RAiDER/statsPlot.py#L23

Few examples for discussion stimulation:

• This does not enforce the date formatting to be checked in the parser: https://github.com/dbekaert/RAiDER/blob/a3548e9f23d6280629f14bd2a15b75bcb5263f35/tools/RAiDER/downloadGNSSDelays.py#L72

• The checking of the bounding box is done in the code and not in the parser. Parser is requiring a string. @Askaholic i assume you want to do this as part of the parser? https://github.com/dbekaert/RAiDER/blob/a3548e9f23d6280629f14bd2a15b75bcb5263f35/tools/RAiDER/downloadGNSSDelays.py#L326-L337

• this does not check the order of the dates or the formating as part of the parser: https://github.com/dbekaert/RAiDER/blob/a3548e9f23d6280629f14bd2a15b75bcb5263f35/tools/RAiDER/statsPlot.py#L70

[Askaholic]

Yea I'm thinking some directory structure like this:

RAiDER/
    cli/
        __init__.py
        validators.py
        parser.py

We would put the parameter parsing functions in validators.py. I think you're pretty much free to do as much input validation as you want in the parsing functions even checking that files exist etc: https://docs.python.org/3/library/argparse.html#type

[jlmaurer]

@dbekaert do you want to close this issue re #82 or leave it open for further work? @Askaholic notes that more could be done.

[Askaholic]

Don't close it, it's far from being done.