| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Sol Jerome <sol.jerome@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If adding an option during the "Main Parser Loop" (for example because of loading
a component for bcfg-lint) a value for the option from the config file is simply
ignored.
After adding the option, the parser first tries to find the value in the command line,
but cannot find it and set the default value from the source code as option value.
After that the value from the config file is set as new default, but because the
option already is in the Namespace, it does not use the new "default" value from the
config file.
This patch simply sets the default value from the config file for the new options,
right after adding it to the parser and so the correct value is used afterwards, if
the parser cannot find the flag on the command line.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This fixes several cases in which <repository> macros would not be
properly processed: options that are not added to the parser yet when
early options are parsed; and config file options whose default value
is used.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_set_defaults_from_config must be called before _parse_config_options
This is due to a tricky interaction between the two methods:
(1) _set_defaults_from_config does what its name implies, it updates
the "default" property of each Option based on the value that exists
in the config.
(2) _parse_config_options will look at each option and set it to the
default value that is _currently_ defined. If the option does not
exist in the namespace, it will be added. The method carefully
avoids overwriting the value of an option that is already defined in
the namespace.
Thus, if _set_defaults_from_config has not been called yet when
_parse_config_options is called, all config file options will get set
to their hardcoded defaults. This process defines the options in the
namespace and _parse_config_options will never look at them again.
|
|
|
|
| |
This is to make the method name more in line with what it does
|
| |
|
|
|
|
| |
This also fixes some extraneous calls in the option parsing loop.
|
| |
|
|
|
|
|
|
|
|
| |
If finalize is called early, then some options will not be parsed
but instead always take the default value (observed with
reporting.transport). Calling finalize once at the end of the
processing lets all options take the values they were assigned in the
config file.
|
| |
|
| |
|
| |
|
|
|
|
| |
It hasn't been parsed at this stage anyway.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This ensures that required positional arguments are handled properly.
If we only reparse the remaining arguments -- i.e., those that were
not understood on previous passes -- then we may parse out all of the
positional arguments on the first pass, and then on a subsequent pass
parse_known_args() will fail because the positional argument is not
provided.
|
| |
|
|
|