Noticed by @guettli on GitHub, this sentence was likely supposed to say
that workers may "be killed" and "start up", where "to start up" is a
verb phrase while "startup" is a single word noun. Clarify by changing
this to read "to stop and start".
I was reading the documentation to configure another application successfully deployed with Gunicorn, and thought the documentation here could be improved a bit for clarity.
* Use code highlighting for the names, to indicate they are the names to use in the Python configuration file.
* Spell out the CLI flags and defaults with "Command line" and "Default" prefixes so it's clear what these are
* Consistently use Python syntax for the defaults, so the types may be more easily understood.
* Split multiple CLI flags with "or" rather than a comma, for clarity and easier copy-paste.
* Improve some descriptions, such as for ``raw_env`` and a header for "Server Hooks".
There is no support for decoding any dictionary supplied on the command
line. The only way to supply a dictionary logging config is through the
configuration file.
Close#1909.
Running gunicorn project.app while having a file called gunicorn.conf.py
in the current directory will read configuration from that file and actually fail
if the file raises an exception.
This change make it clear what is configuration file for Gunicorn.
Using a filename with an extension different than a python extension
was never supported. Also it gives us some room for a proper config file.
* load application from factory function
Use `ast.parse` to validate that the string passed to the CLI is either
an attribute name or a function call. Use `ast.literal_eval` to parse
any positional and keyword arguments to the function. Call the function
to get the real application.
Co-authored-by: Connor Brinton <connor.brinton@gmail.com>
* test coverage for util.import_app
* document app factory pattern
