Closed ntadimeti closed 4 years ago
@ntadimeti is the order of options you specified above (having some options before the mode and some after) a requirement?
@ntadimeti is the order of options you specified above (having some options before the mode and some after) a requirement?
With current implementation, yes.
The other option would be to replicate all of these common options for every mode, which would be cumbersome.
There's another option where we can inherit the common parser as a parent for each of these sub parsers. I tried that initially, there's some issues with conflicting help messages. We will have to turn off the help for default parser, which means when people do python main.py -h
they get no help. They will have to know apriori what modes exist.
Happy to learn more
maybe an option is to have a helper function that adds the common options to a parser, so cmd_args.py can have something that looks like -
def add_common_options(parser):
parser.add_argument(option1)
parser.add_argument(option2)
and each of the sub parsers for train, infer, eval get assed through this function. This way we limit repetitive code, but also duplicate the options across all parsers.
A nicer thing would be to add these to an abstract parser class that train/infer/eval inherit from, but it looks like inheritance is messing with the default parser? The abstract parser should also be inheritable from the default parser, so my gut feeling is it shouldn't break anything. But the common function should work
@avantikalal --FYI.
Everything works just as before. Instead of main.py --train
you will now just provide main.py train
Organize command line arguments into sub-commands train, infer and eval.
There are some common arguments for all modes, those should be specified first, followed by the mode of operation, followed by arguments specific to the mode of operation.
python scripts/main.py $mode -h prints out the command line arguments specific to the $mode.