The Arbiter is smart about getting the CWD; first it checks the CWD
environment (which doesn't resolve symlinks), then it falls back to the
python os.getcwd() (which does resolve symlinks). However, the Arbiter
is the only place that does this, which will then do the right thing
when we reexec. However, when reloading the Arbiter, it won't pick up
changes if the symlink has changed.
By changing the *app.py entry points to also use the same method for
determining the CWD, we'll insert a symlink path into the first location
in sys.path. Then our reloaded app will correctly pull in any new
changes.
Add options to setup logging to syslog:
- `--log-syslog`: enable syslog. It default to `/var/run/syslog` on darwin,
`/var/run/log` on freebsd, `/dev/log` on openbsd and udp://localhost:514 for
other platforms.
- `--log-syslog-prefix: Pass the parameter to use as the program name
- `--log-syslog-to`: Setup the syslog address to send message. Address startinf
by udp:// will send to udp, unix:// to a unix socket and tcp:// to tcp (useful
for rsyslog)
fix#452 .
This patch makes sure that we now handle correctly bytes and native
strings on python 3:
- In python 3, sockets are now taking and returning bytes.
- according to PEP3333, headers should be native strings and body in
bytes.
Now you able to use existed type instance or factory method to create and customize class during in-code configuration.
E.g.:
>>> settings.set('worker_class', MyWorkerClass)
>>> settings.set('worker_class', lambda: MyWorkerClass)
All other formats still valid.
- handle new way to launch applications in django 1.4
- simplify the way we discover the project path and settings
- add --pythonpath & --settings options for django applications
- still compatible with older versions (>=1.1)
-handle DJANGO_SETTINGS_MODULE env.
close#283, #275, #274, #241
* Always log the exception locally
* Still only pass the exception in the HTTP response if
debug is turned on.
* Slight cosmetic changes to the actual HTML of the error
response.
We now treat Server and Date headers as hop-by-hop headers (ie, drop them)
so that they aren't repeated. While not technically hop-by-hop, the WSGI
spec says we should take the role of an origin server.
Fixes#79
This allows people to pass info from the command line to a WSGI
application. See examples/alt_spec.py for code that uses this
method. Example invocation:
$ gunicorn 'alt_spec:load("my arg here")'
Notice the single quotes to avoid shell escape semantics.
Closes#56Closes#40
* All configuration and bootup is handled by the Application objects.
* There is now a strict ordering on the precedence of configuration
settings:
1. Each option is given a default value of some sort in options.ini
2. Any detectable framework configuration settings override the hard
coded defaults for options. Currently, only Paster applications
have support for this.
3. Anything that is specified in a Gunicorn configuration file (by
default gunicorn.conf.py) overrides what was possibly set by a
framework specific configuration source.
4. Anything specified on the command line reins supreme. The command
line is the final authority on a given configuration option.
Though, not all configuration options are available via command
line.
* Configuration metadata is pulled from an options.ini. In the future I'll
use this to build the example gunicorn.conf.py and the config.rst file
in docs/site/config.rst.
I haven't tested the differences thoroughly. The next item on my agenda
is to figure out a way to start testing Gunicorn that doesn't make my
eyes bleed.
