I'd accept a PR to allow --app to be used to make the positional arg optional, so long as it remains bw-compat and validates properly that only one of the args can be supplied.

Hard disagree on config files vs CLI args tho, as far as version controlling config files tend to be far superior. :-) I do understand the desired flexibility between CMD and ENTRYPOINT in the case of a Dockerfile, and hence would support the feature request.

Hi! So, I'm so so involved in waitress these days, but I still make heavy use of it. I was the person who committed runner.py, and everything I state subsequently should be be taken through that lens, for good or ill.

waitress-serve was implemented the way it was for a specific set of reasons. There were certain compatibility requirements it had surrounding Python 2 that meant getopt was the only reasonable option. If I could've used argparse or something more flexible at the time, I would've. With the transition to Python 3, those reasons disappeared. I'd fully encourage you to submit updated command-line parsing using a more modern parser. It's long overdue. There's literally code hanging around to cope with issues in Python 2.6 quirks still there! That very much needs to go.

Secondly, there was the requirement to keep compatibility with the Adjustments class. This limited what I could do a lot at the time, but it at least meant that I had to pay extra attention to keeping the public interface friendly.

There is a lot of code in runner.py and adjustments.py that could go away, and I'd very much encourage you to submit a PR to fix it all. It wouldn't even necessarily be all that difficult: you'd probably end up with fewer lines of code these days.

You could also implement what you're looking for trivially around line 271-276 (also lines 261-263) by checking kw for your new argument and skipping much of that code. I would be very straightforward to do, and between runner.py and adjustments.py, the code is pretty straightforward.

Hard disagree on config files...

I will add up a little, if you please. 😊

The point is that you already have those "configs" in files, somewhere. And when you keep propagating them from files ("sources") to another files, in other "pipeline stages" and environments, eventually you will miss some file - it will go out of sync with source. Crazy things will happen.

Instead, you need to eliminate as much "(configuration) files" as you can, and reconstitute everything from one single source of truth, providing applications and services it's configuration with chain-loading. More on that topic can be read here: https://www.skarnet.org/software/s6/overview.Html.

I'm planning to dive into code on weekends.

Could someone please assign this issue to me?

@tribals in most open source software projects, no one assigns issues, including this one. You can make a comment to let other developers know you are working on it, and create a pull request.

Here is first take on this:

• https://github.com/tribals/waitress/tree/refactor-cli

Here is first take on this:

• https://github.com/tribals/waitress/tree/refactor-cli

Feel free to create a PR and mark it as draft. This will make it easier to track progress for us as maintainers.