Opened 11 years ago

Last modified 8 months ago

#21978 assigned New feature

Add optional gunicorn support to runserver

Reported by: Tim Graham Owned by: Berker Peksag
Component: Core (Management commands) Version: dev
Severity: Normal Keywords:
Cc: berker.peksag@…, cmawebsite@…, uranusjr@…, Carlton Gibson, Tom Forbes Triage Stage: Someday/Maybe
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

gunicorn has added a --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."

Change History (13)

comment:1 by Berker Peksag, 10 years ago

Cc: berker.peksag@… added
Owner: changed from nobody to Berker Peksag
Status: newassigned

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]

  1. Add a new "rungunicorn" command.

Options:

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!

comment:2 by Tim Graham, 10 years ago

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?

comment:3 by Berker Peksag, 10 years ago

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!

comment:4 by Collin Anderson, 10 years ago

Cc: cmawebsite@… added

comment:5 by Berker Peksag, 10 years ago

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

comment:6 by Berker Peksag, 10 years ago

Has patch: set

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.

comment:7 by Tim Graham, 10 years ago

Patch needs improvement: set

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 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.

comment:8 by Tim Graham, 9 years ago

See also a request on django-developers to add SSL support to runserver. It discusses some alternatives to gunicorn.

comment:9 by Tzu-ping Chung, 9 years ago

Cc: uranusjr@… added

comment:10 by Carlton Gibson, 7 years ago

Cc: Carlton Gibson added

comment:11 by Tom Forbes, 6 years ago

Cc: Tom Forbes added

comment:12 by Tom Forbes, 6 years ago

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).

comment:13 by Mariusz Felisiak, 8 months ago

Triage Stage: AcceptedSomeday/Maybe

It seems that there are more questions than answers, so changing it to the "Someday/Maybe".

Note: See TracTickets for help on using tickets.
Back to Top