Trying to refactor CLI arguments parsing in order to support required, non-positional --app
argument
#441
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #439.
At this time, it contains only re-write of parsing to stdlib's
argparse
. You can test overall "look & feel" just by runningwaitress-serve
with--help
, and other arguments.Not all parsing is done yet, but I think the whole
Adjustments
is not needed anymore - evenargparse
is powerful enough to handle common types, but "not so common" also - take a look at-4/-6
args (those was not there already, but they go in the style ofip
fromiproute2
- is it good thing at all?)Another observation is that there is "boolean" options, but not all of them passed/works the same: some use
--arg/--no-arg
notation, but some works just as "if it passed then it's true" (but there also "reverse", notable example is--call
). Should they all be reworked to--[no]-arg
form, or something other?