Positional arguments aren't necessary for determining where to
load configuration anymore and is safe to keep both options and
arguments to be forwarded for later parsing after configuration is
loaded.
Now that preliminary options are registered with the preliminary parser
on the `Application`, leverage that for parsing known options.
This important change removes the `Application.option_manager` from
being responsible for pre-configuration parsing and the workarounds
needed in the `Application.parse_preliminary_options_and_args()` to
account for the fact that `Application.option_manager` was aware of
*all* options, not just the options necessary for pre-configuration
loading. A following commit will address removing these workarounds.
The preliminary options and arguments returned from
`.parse_preliminary_options_and_args()` are now all threaded through to
the appropriate methods during initialization.
This is the initial step towards removing state from the `Application`
object during argument parsing and handling. The goal is to remove
`Application.prelim_opts` and `Application.prelim_args`.
`Application.parse_preliminary_options_and_args` was previously, against
expectations, treating empty lists passed as the `argv` argument the
same way it treated `None`s.
This has been addressed and the correct behavior tested for in a unit
test of the `Application` class.
See issue #518 for details.
By splitting out the logic to retrieve and return the formatting class
for an application, we can test it more easily and increase our test
coverage of this critical logic.
Refs #320
If we handle an exception, or early exit, or really anything, we should
exit non-zero (and we used to). This was a minor oversight.
Closes#209Closes#248
