Add a runservercp command which uses cherrypy as the main server (allows for multiple threads)

[lakin@…]

Stuff like: ​http://www.djangosnippets.org/snippets/999/ can't be tested on the development server cause the main development server is single threaded. CherryPy provides a production ready wsgiserver that is written in complete python and is a great alternative to the built in one.

This is a patch for a runservercp which takes the same arguments as the main development server.

[lakin@…]

A runservercp command which allows one to use the cherrypy server instead of the built in one.

[Joey Wilhelm]

I'm going to guess that this ticket is going to be a wontfix.

For recent discussion of multi-threaded operation, see ticket:3357 and ​http://groups.google.com/group/django-developers/browse_thread/thread/442b00303f6b4fb5

[Russell Keith-Magee]

Tarken: Good guess :-)

While this is a reasonable solution for the particular problem you have posed, it's a niche problem, and we're not going to add a dependency on CherryPy to the Django core in order to solve a niche problem.

However, I heartily encourage you to publish this as a snippet or maintain it as an external application.

[Lakin Wecker]

Hi Guys,

I'm not re-opening the ticket but I did want to suggest a few more options before fully giving up.

I realize that dependencies are not something to be added lightly, but from my understanding this command won't be imported unless it's directly run. So most people may never even notice the import cherrypy statement. This lowers the effect of the alleged dependency to almost none. If someone notices the command and tries it without cherrypy installed I could make it print out a warning about the lack of CP and then fall back to the built-in server?

So, I guess I'm saying that it's not really a full-blown dependency, it only becomes a dependency if/when you need to solve that niche problem which is when its useful. Maybe django could benefit from a set of not-officially supported commands that are included with django so that when someone needs them, they're easily available? For instance if I push this out somewhere external to django the end user who wants to use it must install *both* this code and cherrypy. If we included it, it would be just cherrypy that was required.

Any chance I can get this reconsidered?

[Russell Keith-Magee]

lakinwecker: You are correct in saying that you only need the dependency if you try to use the command. However, including something in core isn't just a matter of satisfying dependencies. There is also the matter of working out how this new piece fits with all the existing pieces.

By including this in core, we would effectively be blessing a new method of Django deployment. We already have a bare-bones server for testing purposes, and this server is deliberately hobbled to discourage people using it for real deployments. We don't want to provide a second development server that we don't want people to use, especially as a CherryPy server almost _could_ be used for a real deployment.

On top of this, a CherryPy webserver can survive as an external command. Since keeping this feature out of core doesn't actually prevent anyone from using it, IMHO the cost of including it exceeds the value by a significant margin.

However, if you really feel strongly about this, bring it up on the Django-developers mailing list. If you can get support for the idea amongst other core developers, I'm happy to be overruled.

[Lakin Wecker]

russellm: The cherrypy _can_ be used for real deployment. It'd be very similar to your runfcgi command. In fact for many site's CherryPy's WSGIServer can handle the traffic just fine. I mean, it might be slower than apache for very high loads, but apache is slower than nginx for many purposes, but you don't discriminate against it for that reason.

I'm still very much of the opinion that this is a valid ticket - but don't have the time to support it on the django developers mailing list. Maybe someone else with the time and energy can bring it up.