Command line argument parsing

Development
1

I am experimenting to replace present command line parsing in gramps/cli/argparser.py with Python-library argparse but I stumble upon an unexpected issue.

Gramps may be started from a console, in which case the command line is exactly what user typed. Gramps may also be started from the desktop, in which case the desktop manager will add “technical” options related to the widget library, mainly GTK+ but other desktop manager may be used like Qt for Plasma Desktop, like --screen= or --display=.

These “technical” options must not be considered errors by the parser which must ignore them. This is handled by adding them in LONGOPTS=[…] in gramps/gen/const.py. They will be takien into account later when a GrampsApplication(Gtk.Application) is created for GUI operation.

However this results in two problems:

  1. the need to enumerate the widget options so that they are not considered errors and a constraint on source code maintenance to keep the list up-to-date
  2. a possible discrepancy if Gramps is launched in a non-GTK+ desktop (but with GTK+ library installed) where the desktop will provide options related to its own library.

How can we liberate Gramps from these “technical” options in order to focus command line parsing only on Gramps matter?

PS: HELP string shows a --load-module options withut explaining it. It is not processed in Gramps, either. I doubt it is a Python interpreter option. Could it be a GTK+ option? In which case why was this one explicitly included in the Help string and not the others?

2

See: 6537: Gramps starts the GUI even in command line mode the last comment mentions “this bug ticket is about dependency cleaning”. Gtk should not be imported when it is not needed (i.e. in command line mode).

3

Thanks for the pointer.

I really don’t know how to handle the case. Decision on whether to go for GUI or not can be made only after parsing the command line. This can be done in various ways but the possible GTK+ options added by the desktop manager really complicates the analysis. They must be ignored at this stage but there is no well-defined exhaustive list. And this list might be different if the desktop is based on a different widget library (Qt in my case but I didn’t see any “strange” option kicked in because I presently experiment in CLI mode).

Once the decision is made, an application object for GUI mode can be created and the initialisation method retrieves the options it is interested in.

The hard point is the possible options in the first stage. I’d like not to give a list. But then, I get an error when I meet one of these “stray” options and I can’t emit a meaningful warning for an unknown option (not in the GTK set).