Parsers are architected in a way where they all inherit from a top level parser that defines a bunch of stuff which is supposedly shared. Only, some of this stuff if not used in some commands, bloating the help text with unnecessary and wrong information, because those options don't actually do anything.
E.g.: fprime-util format --help will print those options
-d DEPLOY, --deploy DEPLOY
F prime deployment directory to use. May contain multiple build directories.
-p PATH, --path PATH F prime directory to operate on. Default: cwd, /Users/chammard/Work/fp/fprime-tools.
--build-cache BUILD_CACHE
Overrides the build cache with a specific directory
-v, --verbose Turn on verbose output.
--ut Run command against unit testing build type
We should find a way to remove those extra parsing options when they are not needed. Somehow, it isn't as straightforward as you'd think to remove an argument from a parser. This may be a hint that our parser architecture is not adapted to the growing functionality of fprime-util, which doesn't only revolve around builds anymore.
LeStarch
commented
1 year ago
Feature Description
Parsers are architected in a way where they all inherit from a top level parser that defines a bunch of stuff which is supposedly shared. Only, some of this stuff if not used in some commands, bloating the help text with unnecessary and wrong information, because those options don't actually do anything. E.g.:
fprime-util format --helpwill print those optionsWe should find a way to remove those extra parsing options when they are not needed. Somehow, it isn't as straightforward as you'd think to remove an argument from a parser. This may be a hint that our parser architecture is not adapted to the growing functionality of
fprime-util, which doesn't only revolve around builds anymore.Rationale
Un-bloat help texts.