Tim, Thanks for taking the time to respond to this and sending those links. I familiarized myself with the gunicorn issues list when Gert suggested using it, but I was unaware of #21978.
As the ticket suggests I don't think it's the current goal to deprecate the runserver command entirely (correct me if I'm wrong) as it offers validation, migration checking, switching settings, etc. by virtue of the base Django command functionality. In perusing that ticket and its comments I noticed a few agreeable ideas: 1. https://code.djangoproject.com/ticket/21978#comment:1 suggests having a --gunicorn flag 2. https://code.djangoproject.com/ticket/21978#comment:2 suggests a perhaps better option of assuming you'd want to use gunicorn if it were installed 3. https://code.djangoproject.com/ticket/21978#comment:6 enhances the automatic gunicorn paradigm with the --no-gunicorn option For reference the most recent PR associated with this ticket was https://github.com/django/django/pull/3461. Of particular note and relevance to this discussion was @cancan101's question on Nov 18th 2014 about whether or not SSL/TLS would be supported by the PR. It looks like the discussion was subsequently dropped and more recently the PR was closed due to inactivity. Taking a look at gunicorn, Windows support is slated for R20.0 which has no stipulated release date. Furthermore, there is no active branch indicating any progress toward supporting Windows, nor any substantial discussion on the issue since Sep 22, 2014. This is despite the fact that it was originally suggested over two years ago. With all that said I'm in favor of what you suggest -- rely on gunicorn where possible. However I don't think what I'm suggesting (and have already implemented) fundamentally interferes with #21978. As far as I can tell the django.core.servers.basehttp module exists solely for the runserver command. And the contents therein aren't so much of a homegrown webserver as they are convenient subclasses to Python's inherent wsgiref.simple_server. The onus of maintenance lies largely in the Python codebase. The django.core.servers.basehttp module could be easily renamed django.core.servers.wsgi and serve as a compatibility module (much like six) that could make runserver function with or without gunicorn depending on whether or not it were installed. Should this discussion otherwise be summarily abandoned, I maintain that --certfile and --keyfile arguments to enable SSL/TLS directly from runserver are a good idea, even if that simply means a CommandError is thrown if gunicorn isn't installed as per the goal of #21978. Regards, Steven On Monday, May 11, 2015 at 9:34:45 AM UTC-4, Tim Graham wrote: > > Hi Steven, > > I'm in favor of trying to switch runserver to use gunicorn instead of > expanding the functionality of our own homegrown webserver ( > https://code.djangoproject.com/ticket/21978). Windows support still > remains an unsolved issue (https://github.com/benoitc/gunicorn/issues/524), > but I don't think the lack of Windows support should stall that effort or > justify adding SSL support to the homegrown runserver. > > Tim > > On Saturday, May 9, 2015 at 1:22:33 PM UTC-4, Steven Berry wrote: >> >> From what I understand that's predicated on a *nix environment. So while >> it's a perfectly reasonable solution, and one which I may end up using >> myself, it doesn't cover all bases. >> >> I can certainly understand if the goal is to keep runserver as slim as >> possible so as not to reproduce functionality found elsewhere. However, I'd >> be more comfortable with that demarcation erring on the inclusive side of >> rudimentary TLS support, which in today's internet is more or less a >> requirement for production development. Obviously runserver shouldn't start >> to reproduce more functionality from gunicorn such as UNIX sockets (I'm >> sure there's more, but I'm less familiar with it than I'm sure you are). >> >> I defer to better and more experienced judgement, but as a developer and >> end-user those are my thoughts and persistent pain points. >> >> Regards, >> Steven >> >> >> On Saturday, May 9, 2015 at 12:36:50 PM UTC-4, Gert Van Gool wrote: >>> >>> Hi Steven, >>> >>> It might be handier to use gunicorn with SSL support[1] and since there >>> is already a section in the Django documentation on how to use gunicorn in >>> a project[2]. >>> >>> >>> [1]: http://gunicorn-docs.readthedocs.org/en/latest/settings.html#ssl >>> [2]: >>> https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/gunicorn/ >>> >>> -- Gert >>> >>> Twitter: @gvangool <http://twitter.com/gvangool> >>> Web: http://gertvangool.be >>> >>> On Sat, May 9, 2015 at 4:19 PM, Steven Berry <[email protected]> >>> wrote: >>> >>>> While working with an OAuth library I was running into some issues >>>> signing requests on a local development server due to lack of HTTPS. >>>> >>>> To solve this problem I was deploying web application code to a VM with >>>> a shared folder or SCP and running an TLS-enabled nginx server. Obviously >>>> the development/test latency here is unacceptable. I looked into what >>>> solutions were out there and found a Django plugin django-runsslserver ( >>>> https://github.com/teddziuba/django-sslserver). I installed this app, >>>> but was disappointed by a few things: >>>> >>>> >>>> - The included certificates didn't work due to an EOF openssl error >>>> - I was required to install an additional app (even just doing a += on >>>> the INSTALLED_APPS tuple in a separate development settings module >>>> felt a bit wonky) >>>> - I now had command bifurcation when running development servers -- >>>> runserver, runsslserver, and testserver (which in turn didn't >>>> support SSL) >>>> - The code was necessarily repetitive because Django does not >>>> currently abstract the django.core.servers.basehttp module enough >>>> for this purpose >>>> >>>> I felt like this was something Django should just optionally support >>>> out of the box for simple use cases such as my own. I forked Django and >>>> switched my installed version in my virtual environment to my fork with >>>> "pip >>>> -e". I used this myself for a while, but I thought my modest change >>>> would be objectively useful for others and would be relatively trivial to >>>> review and implement. >>>> >>>> For reference I developed a fix here >>>> https://github.com/sjberry/django/commit/c8e808d70f4a0ac6ebf4634576a2538b4f35b83e >>>> and >>>> subsequently submitted a PR here >>>> https://github.com/django/django/pull/4633. Though the PR was >>>> admittedly out of order due to my inexperience with the contribution >>>> protocol. >>>> >>>> Let me know if I'm off base here. >>>> >>>> Regards, >>>> Steven Berry >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/django-developers. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/40207727-f555-4c1a-bdc4-dcc40e9be935%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/40207727-f555-4c1a-bdc4-dcc40e9be935%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0e46cbcc-6bf6-4e54-bdad-d13d3a7f81a6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
