As the title suggests I have related proposals that could be proposed separately, but make more sense to discuss together.
Rationale:
While helping another newcomer to django and noticing that they had used runserver in their production hosting environment, I wondered if the name of runserver could be clearer to beginners in terms of the intention of its use.
The solution is me is two-fold:
Rename runserver to devserver or similar (run_devserver), the key would be to have dev or similar in the name somewhere. This makes it explicit that the command is for a development environment and not production.
Introduce a prodserver or similarly named command to run a configured wsgi/asgi server or other commands via settings. Initially, this could be done via subprocess or expanded to call the relevant Python APIs in the wsgi/asgi servers. The goal here is to provide a common interface for running Django in production but doesnât limit calling a wsgi/asgi server directly. Additionally, I donât believe this should necessarily cover all possible use cases to run Django in production but provide an easy starting point for newcomers.
This could easily be split into two separate tracks of work.
For the rename, it would be adding devserver (or similar) in addition to runserver, then deprecating runserver with the normal deprecation policy.
The prodserver command can easily be tested as a third-party package, to begin with, however, having the goal of a clear way to run development and production ought to be eventually available by default out of the box. A DEP is also likely required here to ensure that all desirable use cases are covered.
I will likely give the prodserver package a go in the next week or so.
I love the concept of âhere is something to get you started.â (in this case, started = deployed)
and they can/will adjust things as needed later when they run into problems. In this case, I suspect most people donât need âfancyâ deployment (large scale, jython, other niches) and so something simple will be fine.
Renaming this does make sense to me - even in my limited exposure to user support - I regularly see people thinking this is how theyâre always meant to run their application.
<opinion>
Iâm a strong -1 for renaming runserver. I think youâre creating a lot of work for some percentage of the user-base for no benefit to them - and, IMO, minimal benefit to those coming along in the future.
Aside from all the tutorials, books, and other educational material becoming obsolete, you also have third-party tooling that overrides the runserver command for its own purposes (e.g., Channels), and all the scripts and other tooling built on using runserver as its base (e.g., running and debugging Django in Visual Studio Code.) This change invalidates every workspace file that anyone has ever created and modified for every Django project that gets upgraded to a release with this change in it.
I think that this, like some other historical decisions, fits into the category of being too-well entrenched to make it worth changing. </opinion>
Oh, Iâm probably a 0 on that. I donât have any objection to including it, but I donât have any environment where I could see using it. I use either supervisord or a systemd control file to run the Django processes for any system running a persistent process. Running a production web server from a command shell just seems like an invitation to a whole host of problems.
Actually, continuing to think about this, Iâm going to revise my opinion to be a -1 for this as well.
I can think of two questions I have answered here in the past that would have raised issues along those lines.
One person asked why their project stopped running when they ran ./manage.py runserver & and then logged off, and another person asked why it would be a bad idea to run their server in a screen session.
I think that having a script to run a production server is just going to encourage this type of thinking.
I can see some value in bundling or making a default production-quality server available, but I worry about the message that it sends by encouraging its use directly from the command line.
Iâm also -1 for both proposals. IMO this will create unnecessary noise, citing the docs:
Nowâs a good time to note: donât use this server in anything resembling a production environment. Itâs intended only for use while developing. (Weâre in the business of making web frameworks, not web servers.)
Iâm also -1 on both proposals for the same reasons as Ken and Mariusz. A production grade web server is its own project, especially when you start considering things like WSGI and ASGI support, TLS, performance, ⌠The landscape is always changing too, for example this week I learned about nginx unit. I think if thereâs any management command to launch a configured production-grade server, itâs better in a third-party package so it can evolve separately and Django isnât stuck maintaining it.
I tend to avoid offering an opinion on a lot of things because I still feel like I work in more ânicheâ areas than most, and a lot of what is proposed doesnât affect me either way. If something doesnât jump out at me right away as being a problem, I tend to ignore the proposal because I donât see much value in me offering a lot of â+/-0â opinions.
Quite honestly, I didnât give this the thought it deserved. I recognized that the docs and tutorials would need to be changed - I didnât think of third-party materials at all. So if anything, the delay is my fault for not giving your proposal the consideration it required.
I had mentally set your proposal aside, being a solid â-0â by thinking that Iâd have to change a couple scripts, and so considered it a âminor annoyanceâ that I could live with.
So why now? Your recent post was a reminder of the proposal. It wasnât the ticket per-se, but seeing the post itself reminded me that this was something âin progressâ. That, combined with a couple of recent topics here in the forum, is what got me thinking about it some more - making me realize that my opinion on ârunserverâ is stronger than a â-0â.
This can have some recommendations (around cross promoting in other sub communities such as Discord, Mastodon etc) as well as some expectation management (around time, maybe that âconcensusâ is not concretely defined).
The question âwhat is concensusâ or âhow do I gather concensusâ imo classes as a frequently asked question.