[Django] #21978: Add optional gunicorn support to runserver

Django

unread,

Feb 7, 2014, 3:46:15 PM2/7/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner: nobody
Type: New | Status: new
feature | Version: master
Component: Core | Keywords:
(Management commands) | Has patch: 0
Severity: Normal | Needs tests: 0
Triage Stage: Accepted | Easy pickings: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
UI/UX: 0 |
-------------------------------------+-------------------------------------
gunicorn has added a [https://github.com/benoitc/gunicorn/pull/682
--reload option for code reloading] which should lower the barrier of
entry to removing our own HTTP server functionality.

Simply deprecating and removing the `runserver` management command
entirely may not be desirable. As Loic noted on IRC "even if we use
gunicorn, we still need some special handling for the dev server, we run
validate() and now there are some migrations checks going as well. So
would we really deprecate runserver? rather than just change the
underlying webserver it wraps?"

Michael Manfre also expressed concern the gunicorn does not currently work
on Windows.

Aymeric suggested: "optional support for gunicorn could be an interesting
start."

--
Ticket URL: <https://code.djangoproject.com/ticket/21978>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,

May 19, 2014, 7:13:20 PM5/19/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

* cc: berker.peksag@… (added)
* owner: nobody => berkerpeksag
* status: new => assigned

Comment:

I have a WIP patch for this ticket. Before open a pull request, I'd like
to discuss structure of the runserver command.

Current choices:

1. Add a new "--gunicorn" option to runserver: ./manage.py runserver
--gunicorn -c gunicorn_conf.py

If the -c option is not given, use existing runserver options e.g.:

./manage.py runserver --gunicorn [--noreload] [optional port number, or
ipaddr:port]

2. Add a new "rungunicorn" command.

Options:

* -c conf.py
* -b --bind
* -w --workers
* -l --logfile
* --debug
* --reload
* probably other options from
http://docs.gunicorn.org/en/latest/settings.html

Use cases:

* Use default options: ./manage.py rungunicorn (same as ./manage.py
runserver)
* Read config information from a file: ./manage.py rungunicorn -c conf.py
(this is the configuration file used by Gunicorn)

Thoughts?

Thanks!

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:1>

Django

unread,

May 19, 2014, 9:21:00 PM5/19/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Comment (by timo):

I envisioned a more transparent integration. I was thinking that if
gunicorn is installed, then `runserver` would use that automatically
(passing data to `--reload` and `--bind` from the current `runserver`
options). You can always use the full gunicorn integration if you need the
other options. Do you think that approach would be too limiting from a
user perspective?

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:2>

Django

unread,

May 19, 2014, 10:13:51 PM5/19/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Comment (by berkerpeksag):

> I was thinking that if gunicorn is installed, then runserver would use
that automatically (passing data to --reload and --bind from the current
runserver options).

Ah, that is a good idea. Also, we can pass the `settings.DEBUG` setting to
Gunicorn's configration.

> Do you think that approach would be too limiting from a user
perspective?

No. I think that approach is a good start. It's a development server
afterall.

BTW, my WIP patch is at https://github.com/berkerpeksag/django/compare
/ticket-21978_gunicorn I will update it later.

Thanks!

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:3>

Django

unread,

Oct 30, 2014, 2:27:16 PM10/30/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Changes (by collinanderson):

* cc: cmawebsite@… (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:4>

Django

unread,

Nov 3, 2014, 5:57:49 AM11/3/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Comment (by berkerpeksag):

I'll update my branch to address comment:2 and open a PR in a day or two.

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:5>

Django

unread,

Nov 3, 2014, 9:44:33 AM11/3/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Has patch: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by berkerpeksag):

* has_patch: 0 => 1

Comment:

https://github.com/django/django/pull/3461

I hardcoded the port number in the test, but I couldn't find any helper in
the Django test suite to find an unused port number. Is there a helper
like
https://hg.python.org/cpython/file/default/Lib/test/support/__init__.py#l578

Also, should I add an `--disable-gunicorn` option to runserver? Currently,
there is no way to disable gunicorn in runserver.

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:6>

Django

unread,

Nov 28, 2014, 8:57:44 AM11/28/14

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Needs tests: 0 | Patch needs improvement: 1

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by timgraham):

* needs_better_patch: 0 => 1

Comment:

`LiveServerTestCase` has some logic to find an unused port.

I don't see a need for an option to disable it (if you don't have gunicorn
installed, it's disabled anyway, right?)

By the way, it seems that [https://github.com/benoitc/gunicorn/issues/524
Windows support] is not too far off for gunicorn so let's wait to merge
this until that's done. Then we can see if this is comprehensive enough to
deprecate the non-gunicorn version.

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:7>

Django

unread,

May 27, 2015, 9:34:31 AM5/27/15

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

| berkerpeksag
Type: New feature | Status: assigned
Component: Core (Management | Version: master
commands) |

Comment (by timgraham):

See also a [https://groups.google.com/d/topic/django-
developers/PgBcSEiUdw0/discussion request on django-developers] to add SSL
support to runserver. It discusses some alternatives to gunicorn.

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:8>

Django

unread,

Apr 10, 2016, 10:35:06 AM4/10/16

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------
Reporter: timo | Owner:

Changes (by uranusjr):

* cc: uranusjr@… (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:9>

Django

unread,

Feb 14, 2018, 3:36:39 AM2/14/18

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------

Reporter: Tim Graham | Owner: Berker
| Peksag

Changes (by Carlton Gibson):

* cc: Carlton Gibson (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:10>

Django

unread,

Aug 9, 2018, 7:40:56 PM8/9/18

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------

Changes (by Tom Forbes):

* cc: Tom Forbes (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:11>

Django

unread,

Aug 9, 2018, 7:50:54 PM8/9/18

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------

Comment (by Tom Forbes):

It's been a while since the django-developers thread with some
alternatives, and since then there are a few new viable options with
Windows support which seems to be the big blocker here. I'm not sure if
support will ever be added to Gunicorn.

Waitress seems quite nice:
https://docs.pylonsproject.org/projects/waitress/en/latest/

And I've had good results with aiohttp-wsgi: https://aiohttp-
wsgi.readthedocs.io/en/stable/wsgi.html

`--reload` is a nice feature to have handled upstream, but their
implementation is not particularly advanced or complicated, and may be
harder to extend
(https://github.com/benoitc/gunicorn/blob/master/gunicorn/reloader.py).

--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:12>

Django

unread,

Mar 8, 2024, 3:02:06 AMMar 8

to django-...@googlegroups.com

#21978: Add optional gunicorn support to runserver
-------------------------------------+-------------------------------------

Reporter: Tim Graham | Owner: Berker
| Peksag
Type: New feature | Status: assigned

Component: Core (Management | Version: dev

commands) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:

| Someday/Maybe

Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Mariusz Felisiak):

* stage: Accepted => Someday/Maybe

Comment:

It seems that there are more questions than answers, so changing it to the
"Someday/Maybe".
--
Ticket URL: <https://code.djangoproject.com/ticket/21978#comment:13>

Reply all

Reply to author

Forward