Currently, the usage of waitress-serve is as follows:

$ waitress-serve --help
Usage:

    waitress-serve [OPTS] MODULE:OBJECT
<...>

This is rather inconvenient, as "application" argument is rarely change over the lifetime of project. But, this forces to pass all the arguments that definitely change before, but still keep "app" somewhere and append it in the end. This makes changing those arguments difficult.

For example, when deploying Flask application (running in dev. server) to Docker, one can write Dockerfile like that:

ENTRYPOINT ["/app/bin/flask", "--app", "your.awesome:app"]
CMD ["run", "--host", "::"]

This makes resulting image something like "runnable artifact" - you can docker run -it your/awesome:latest - and it will work out of the box. Besides that, you can also docker run -it your/awesome shell - and it will throw you right into "application" internals, inside plain old Python REPL. Among those, you can just pass Flask arguments directly to container - and it will work "as expected".

But this is all for development. What about production? Translating this example to waitress-serve yields this:

ENTRYPOINT ["/app/bin/waitress-serve", "your.awesome:app"]
CMD ["oops, nothing to write here..."]

This will fail, because you must pass "arguments" (CMD in Docker vocabulary) before MODULE:APP - and this is unachievable with waitress-serve.

Although one still can implement this logic in "his own CLI, wrapping waitress API directly" - but I argue exactly against that - this is unfortunate that every Python Web programmer need to implement it's own "wrapper" for so much common things - this leads to duplication of logic, maintenance burden and creeps design of application to the dark. The logic is so simple that waitress-serve should be used literally for all deployments.

So, it would be nice to have non-positional, required argument to pass application module/instance to waitress-serve.

Side-note on configuration files: they make configuration harder. Better to pass arguments and set environment variables.