Trying to refactor CLI arguments parsing in order to support required, non-positional --app argument
#441
Conversation
tribals
changed the title
--app argument--app argument
tribals
changed the title
--app argument--app argument
|
I am not a fan of adding Also, Remember that Waitress is not always run from the command line, but also run through things like Paste. |
The whole point is that they already exist in long form, so
👌 |
|
I've finished porting args parsing to, you know, I've not touched much It works! 😁 Also, I've fixed almost all tests, but some |
| waitress-serve [OPTS] --app=MODULE:OBJECT | ||
|
|
||
| Required options: | ||
|
|
||
| ``--app`` | ||
| Specify WSGI application to run. |
There was a problem hiding this comment.
You'll break the existing external interface this way.
You should be able to accept the application using both the --app= flag and by passing it as a positional argument.
There was a problem hiding this comment.
I will - but first, I need a general agreement of how everything is implemented, and is argparse "enough" to solve the problem.
On the "positional app argument" - it is not clear now, should this argument be "still first", and for passing app eg. last one should use --app form. Or app should be accept eg. first or last - but this will complicate parsing.
There was a problem hiding this comment.
On "argparse" side, right now there are some cases where it is hard to achieve desired results, eg. mutually exclusive groups of options. For now it can be solved as external "validation" step after parsing, and it will suffice, I think.
|
I am not opposed to this. I am going to need to chew on it for a little bit and then we may want to figure out how to make this work cleaner with the existing Adjustments and or make all of that cleaner. There's just a lot of tendrils in many different locations. |
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-servewith--help, and other arguments.Not all parsing is done yet, but I think the whole
Adjustmentsis not needed anymore - evenargparseis powerful enough to handle common types, but "not so common" also - take a look at-4/-6args (those was not there already, but they go in the style ofipfromiproute2- 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-argnotation, 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]-argform, or something other?