Sorry to bring back an old thread but I was just wondering is there any way to run an async runserver in django 3.2? I can’t find anything in the docs.
I am using uvicorn.run() at the moment but I need to collectstatic my files locally for django admin files to be served. Is there a better solution?
There is no way in the core. The easiest way is probably installing channels and installing it only for local dev, while using whatever other server you want in production.
I didn’t realize that Carlton accepted the ticket about a year ago for getting something into the core. I’ll try and make a pr at least updating the docs to suggest installing channels for local development, and then a pr with some code for anything new.
Yep, echoing this. Channels has a runserver here which you can use.
(Cough) We should be able to build something to handle at least http protocol requests from Python’s http.server. I began looking at this but haven’t had capacity to see it through. That Channels has a runserver means it’s not been pressing. (And 2020/21 
) — Also @massover’s project looked very good IIRC.
In general, no problem raising the old threads: things can and do move slowly in Django-land — glacially, inexorably, … 
— it’s good to keep the discussions together where possible.
Yeah, the key thing here is that Python ships a basic WSGI server in the core set of libraries (wsgiref), but asgiref is a) separate and b) doesn’t contain a reference server, as it’s quite a bit more code to do so.
I think it’s a good idea and we should get there - potentially adding the basic HTTP server required to asgiref if we need, since Django already imports that - but it’s not around yet.
OK… finally approaching the (current) bottom of the Pandemic Backlog™… 
I’ve begun work on what will be Channels v4 (hoping to release, along with Daphne and channels_redis updates around Sept.) Part of this is removing all the AsgiHandler &co code from Channels, instead relying there on Django’s versions, which will be the way forward.
That will leave Channels nice and tight, as (just) the Websockets and HTTP Consumers, Channel Layer, and maybe a few other ASGI utils bits, but little more than that.
One part of this that I think folks would appreciate is breaking the hard dependency on Daphne (and so Twisted). Moving the runserver code out of Channels is required for that.
@massover Would you be up for inputting on the suggested django-asgi-runserver repo, if I create one under the Django org? (No stress if you don’t have capacity, but given the work you already put in, maybe you’d be keen? 
) Ideally we’d be able to remove this package over time — as per the discussion here — but likely it would be around for a couple of cycles (or more) at least.
The Channels runserver is now updated to use django.contrib.staticfiles’s ASGIStaticFilesHandler so creating the package should (
) be a question of migrating that out, and so on.
The previous blocker here was making it easy for beginners to get up and running. I think something like…
pip install channels['runserver']
Plus an adjustment to INSTALLED_APPS is bearable, given I can’t see another way out of that.
Then other things to consider are:
- The
INSTALLED_APPSorder so we don’t fightdjango.contrib.staticfiles.- Clear instructions there win.
- A system check would be a nice-to-have. (Need to check they’re run on every code path…)
- I’d like to remove the
hackcode from Channels that monkey patches thedjango.contrib.staticfilesrunserver if we can.
- The early import for the reactor setup. This is probably fine in the
apps.py— as currently — which is done before middleware are loaded (which is the other suspect).
(These last are mainly notes to self.)
Update: We could just transfer it and keep the name as is… 
This might run too. It may be simpler.
Update: Move runserver command into Daphne. · Issue #428 · django/daphne · GitHub
@carltongibson I have some time, I’ll have a look
Hey @massover — great.
I began here: Added runserver to Daphne. by carltongibson · Pull Request #429 · django/daphne · GitHub — just making Daphne into a Django app so far. If you want to collaborate on that branch, that would be awesome.
I was looking again at this recently. Happy to be shown wrong but IMO it’s not feasible to implement even a simple HTTP server here without bringing more dependencies than it’s worth. (It’s much easier to take an existing “real” server, and provide a runserver command for that.)
Daphne already has one. You add like so:
INSTALLED_APPS = [
"daphne",
...,
]
ASGI_APPLICATION = "myproject.asgi.application"
Other servers could provide the same.
I’ve queried on the Django ticket if we shouldn’t wontfix anything else?
https://code.djangoproject.com/ticket/31626#comment:6
Agreed, Carlton - there’s just enough complexity but I don’t think it’s worth putting it into asgiref.
1 Like
I still don’t get what the current way to get asgi from Django runserver to run is? I have a websocket which doesn’t work when I use runserver, the ideal solution where you can just add --asgi to runserver seemed really nice or even just make it work built in. It seems like people thought a lot about this topic and in the end nothing came from it? Or am I missing something? I’m currently on Django 4.1.1 and don’t know how to get the asgi to work in my dev environment.
You need to have Daphne installed. It installs its own version of runserver to provide asgi.
But, Django itself does not provide websocket support. For that you need a Channels Consumer to serve as the endpoint for that websocket.
(Note: If you have further questions, please open up a new topic in the “Using Django” / “Async/Channels” category.)
1 Like
The Channel Tutorial Part 1 walks you through integrating Channels and Daphne (with runserver integration) into a Django project.