Thanks for the additional background Carlton! I like the idea of having some sort of protocol that folks can follow to make ready-to-use Django server packages (django-webserver [1] is in the same vein), but I'd strive for more. pip install + INSTALLED_APPS is great, but getting to production with that approach can feel like death by a thousand paper cuts. Do that with gunicorn, whitenoise, dj-database-url, etc. and it ends up being a laundry list of things that, in my experience, people rarely get right on the first try and just result in frustration.
It seems like part of the challenge here is reaching parity with the current runserver command, but is that necessary? Running `runserver --dev` locally and getting dev features like autoreloading and then having `runserver` use a different server for a deployed app doesn't seem unreasonable. [1] https://github.com/lincolnloop/django-webserver On Tue, Aug 23, 2022 at 10:14 AM Carlton Gibson <carlton.gib...@gmail.com> wrote: > > Hey Pete. > > Yes... this is a good one. > > It's difficult to see how we can even have an ASGI runserver in core, simply > because there's no SimpleServer equivalent as there is for WSGI, and it's not > clear one is on the card. (HTTP is getting **more** complex, and I can't see > Python bringing such into the standard library.) > So we have to use a third-party dependency for that. > > For the Channels v4 update (in progress now) I'm moving the runserver command > to the Daphne package. This was because folks wanted to use Channels without > the Daphne/Twisted dependency. > > See: https://github.com/django/daphne/pull/429 > > tl;dr — it came out pretty clean TBH. You pip install daphne, then add > "daphne" at the top of INSTALLED_APPS. (There's a system check to make sure > you're not fighting staticfiles.) > > On the back of that I don't see why servers (any servers) can't provide a > runserver command (or a django-* mini-package to go with it) and offer what > they offer in development as well as production. (Obviously that all needs > writing but it's just a management command.) > > Related is strategising the reloader. > https://code.djangoproject.com/ticket/30213 > > We could then host *Protocols* — "Your runserver should do this", "Implement > this for your reloader", and so on — and (maybe) (slowly) replace built-in > options here with either optional dependencies (pip install django["daphne"]) > or recommendations to get going. (pip install django["starter"] maybe). — I > don't know — we seem a long way from that. (I don't suppose wsgiref is going > anywhere too soon is it?) > > But to cut back to your point, I don't know that we need to **include** a > server — just make it easy to get going. These days pip install + a line in > INSTALLED_APPS doesn't seem too much to ask (I think.) > > Was it really 4 years ago Tom left that comment on #21978 😳 (We'd finally > close this as wontfix: Django doesn't ship a webserver.) > > Does that fit in your view, or would that scenario not be good enough? > > Kind Regards, > > Carlton > > On Tue, 23 Aug 2022 at 16:56, Peter Baumgartner <p...@lincolnloop.com> wrote: >> >> Hi all! I'd like to re-open the discussion around >> https://code.djangoproject.com/ticket/21978 >> >> As a "batteries included" framework, Django kind of leaves people to >> fend for themselves when it comes to deployment. This makes it harder >> than necessary for a developer to go from works-on-my-laptop to >> works-on-the-internet. The docs here are great, but also daunting to a >> newcomer https://docs.djangoproject.com/en/4.1/howto/deployment/ >> >> I'd love to see Django provide some sane defaults that people can use >> to deploy a site without having to make a bunch of decisions they >> don't totally understand. >> >> I have two thoughts on how it could be handled: >> >> 1. Similar to the template backends. You get Django's template system >> by default, but you're welcome to swap in Jinja2. I don't believe >> there is a one-size-fits-all webserver, but probably a >> one-size-fits-most. >> 2. Similar to cache/database backends. You define the backend you want >> to use and Django makes some sane choices for you and allows you to >> serve the site via some common `manage.py` command. >> >> For the first option, Gunicorn is a popular choice, but afaik it does >> not work on Windows. Waitress [1] is an interesting option for WSGI >> serving and daphne exists for ASGI. Whitenoise is a reasonable choice >> for serving static files. It doesn't yet support ASGI, but there has >> been some activity on that front [2]. >> >> Thanks! >> >> [1] https://pypi.org/project/waitress/ >> [2] https://github.com/evansd/whitenoise/pull/359 >> >> -- >> 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 django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAC6K9zk5PmcxYWXRdvco1pWXnO%2BHoYoYHf0pg5Mw%3DgmdefZArg%40mail.gmail.com. > > -- > 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 django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAJwKpyTSGPJW%2BmdUADW8eBYaXakesHG9H9dkSzhLxWnCpBdH6A%40mail.gmail.com. -- 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAC6K9zmVDKcpM%3Dc9tyhrp2_K_dzLH5S9zMJcZSXduF9NkcoCKA%40mail.gmail.com.
