Hot take: the cutting edge is stuff we left on the floor in 2009.
-
Will Vincentreplied to Carlton Gibson 🇪🇺 last edited by
-
@wsvincent @carlton @simon @ghickman my hot take (in case you were wondering )
Django should work in production by default (and locally). It should WARN loudly and plainly so people know what settings to change for security reasons.
This is 90% of the settings pain in my book.
Configuring apps has it's own pain scale but most just work once added to INSTALL_APPS and that's what docs are for.
-
@webology @wsvincent @carlton @simon @ghickman I think Python is the only ecosystem where the Dev servers are explicitly not production grade. It's definitely a food-gun for new users, but it does also avoid each framework needing to build and maintain their own.
-
@jake @webology @wsvincent @carlton @ghickman there are plenty of Python servers that are production grade - I use Uvicorn in dev and production all the time
Django’s hesitance to include a “production” server is a historic leftover - there weren’t good options for that 20 years ago!
-
Carlton Gibson 🇪🇺replied to Jake Howard last edited by
@jake @webology @wsvincent @[email protected] @ghickman What would I say there? I’d say, I’d don’t know a single Python project that you wouldn’t (e.g.) put Nginx in front of, but there are plenty I think that Django could wrap with it’s own sauce that would leave us in a net positive.
(Reply with @simon crossed but that too!)
-
Jake Howardreplied to Carlton Gibson 🇪🇺 last edited by
@carlton @webology @wsvincent @[email protected] @ghickman @[email protected] wrapping would work, yes. I guess I was thinking Django would build a new one in-tree. But that's probably not a good idea.
-
Carlton Gibson 🇪🇺replied to Jake Howard last edited by
@jake @webology @wsvincent @[email protected]@[email protected] @ghickman @simon no, probably not
The existing one is the stdlib’s wsgsiref, so not really homebrew either.
-
Simon Willisonreplied to Carlton Gibson 🇪🇺 last edited by
@carlton @jake @webology @wsvincent @ghickman I wonder when Uvicorn will hit 1.0? Their milestone isn't populated at the moment https://github.com/encode/uvicorn/milestone/1
Having Uvicorn as an optional dependency of Django might be a good solution here
-
@simon @carlton @webology @wsvincent @ghickman could go required, but I guess it's quite a large dependency and supply chain. And that's before the debate of which WSGI/ASGI server to depend on begins.
-
Carlton Gibson 🇪🇺replied to Jake Howard last edited by
@jake @simon @webology @wsvincent @ghickman The way forward is to make the WSGI/ASGI distinction transparent. WSGI is still the way to go for most of your application. (Just is). But that “need some ASGI” bit shouldn’t require a whole stack change. Users shouldn’t really have to think about this.
-
Simon Willisonreplied to Carlton Gibson 🇪🇺 last edited by
@carlton @jake @webology @wsvincent @ghickman one of the benefits of ASGI is that it makes serving static files (especially large files) from a Python server a lot more practical, since they don't tie up a thread/worker