CLI scaffolding #4
Conversation
|
|
||
| parser = argparse.ArgumentParser(description=description, epilog=epilog) | ||
| parser.add_argument("--version", dest="version", action="store_true", help="Show version") | ||
| parser.add_argument("verb", nargs="?", choices=fibad_verbs, help="Verb to execute") |
There was a problem hiding this comment.
Do we want to use subparsers here and let the individual verbs define their own flags?
There was a problem hiding this comment.
That was one option, but I was leaning toward a simpler approach for now. It may make sense to go down that route. I still want to think a little more about what we were talking about on Tuesday - namely unlocking many or all of the keys defined in the config file as arguments.
If we go down that route, subparsers may be the right approach. But I'm a little unsure/apprehensive about the order of events needed to load the config file, then use the contents to dynamically generate the parser arguments. In the base case of just looking at fibad's default config file, this isn't too challenging - but as we open this up to plug-in style DataLoaders and Models, each with their own bespoke config parameters - then we have to do some code introspection to identify available classes, grab their default configs, merge that with the base default configs...
Perhaps I'm overcomplicating it 🤷 that's why it would be nice to chat it out 😄
|
|
||
| parser = argparse.ArgumentParser(description="Training with Fibad.") | ||
|
|
||
| parser.add_argument("-c", "--runtime-config", type=str, help="Full path to runtime config file") |
There was a problem hiding this comment.
Do we intend for these config files to be substantially different from one another?
There was a problem hiding this comment.
The major difference that comes to mind would probably be sub-options for the different kinds of models that are implemented within fibad. But those can still probably be handled from within one "generic type" of config file.
There was a problem hiding this comment.
My initial thought here is that the configs should not be substantially different. At this point I would advocate for all the user defined config values to be in the same file, even if they aren't used for a particular action. One obvious follow up would be, why not move the --runtime-config argument up to the main.py. Perhaps we could, but it's kind of nice to see fibad train --help produce output that shows that it expects a config file.
I'm happy to hear counter points to that though. My opinion here isn't a super strong one 😃
Very hand-wavy, a config file might look something like the following. Note that here it includes configs for everything, even if it was just to be used for training now, or just prediction later.
[fibad] # general configs for running fibad???
max_gpus = 4 # just an example
[train] # general configs for training
data_loader = base_loader
model_name = drewtonian # this is type of model, right?
num_epochs = 100 # again, just an example
[train.base_loader]
data_directory = /foo/bar/data
...
[train.drewtonian] # parameters for this model
num_layers = 10
...
[predict] # general configs for prediction
data_loader = base_loader
[predict.base_loader]
data_directory = /foo/baz/new_data
I would love to talk to you both more about the structure of the config file - what is going to be most intuitive and easiest to use... etc.
This is meant to be a starting point for the CLI work, and is meant to give us a place to start hanging more code. The next step after this is integrated in my mind is to implement the user configuration file support.
The current CLI will look something like this:
Getting top level help
Running a fibad action:
Action-specific help
Passing in a config argument
This work is heavily inspired by the CLI work done for Sorcha here: https://github.com/dirac-institute/sorcha/blob/main/src/sorcha_cmdline/main.py