search

NRLMMD-GEOIPS / geoips

Main Geolocated Information Processing System code base with basic functionality enabled.
https://nrlmmd-geoips.github.io/geoips/
Other
14 stars 11 forks source link

Investigate potential bug in CLI command's parser.prog attribute #707

Open evrose54 opened 1 month ago

evrose54 commented 1 month ago

Requested Update

Description

When reviewing PR #641, Jeremy was playing around with the usage statements and realized some of the GeoipsTree code didn't function as expected when the usage defaulted to argparse. For some reason, when using custom usage statements, only the command classes which inherit from GeoipsExectuableCommand have their parser.prog attribute changed to match exactly what that custom usage statement was.

Per argparse.ArgumentParser documentation, parser.prog should match exactly what was provided as the first argument that was not set as a keyword argument. Here's a simple example:

parser = argparse.ArgumentParser("geoips")
print(parser.prog)
# outputs 'geoips'

However, for GeoipsExecutableCommand classes, their parser.prog attributes look like this:

parser = argparse.ArgumentParser("packages")
print(parser.prog)
# outputs 'To use, type `geoips list packages`.'

We couldn't track the source of this issue, and it's possible, though unlikely, that this could actually be a bug on argparse's side. We'll dive deeper into this after the tutorial, as this is a very weird problem that should be solved sooner rather than later.

Background and Motivation

This comes from the reviewal process of @jsolbrig in PR #641.

Alternative Solutions

Currently, we're going to leave this as is so we have stable functionality at the tutorial. However we expect to change the usage statements of the CLI in the future and will need to address this problem.

Code to demonstrate issue

Any CLI command class that inherits from GeoipsExecutableCommand

jsolbrig commented 1 month ago

This issue could potentially be handled in two steps.

  1. Temporarily fix by not setting usage in the parsers and update the unit tests as appropriate to support the change.
  2. Dig into the issue and find the actual problem. I am concerned that this behavior is pointing to a nasty bug that will bite us again eventually and would like to get it figured out.

We might try getting 1 done before the workshop if we have time, but wait until after the workshop to address 2.