On Thu, Apr 11, 2013 at 1:02 PM, Carl Meyer <[email protected]> wrote: > On 04/11/2013 08:31 AM, Gustavo Narea wrote: >> I decided to reimplement the patch I created 3 years ago in a separate >> project (twod.wsgi >> <http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html>), which >> means that it's possible to do this without changing Django. However, it >> doesn't support embedding Django projects because of Django's use of >> global data (DJANGO_SETTINGS_MODULE and django.conf.settings), which I >> think can only be solved by introducing thread locals in django.conf. At >> the moment, the only way to accomplish this would be by proxying the >> second Django site with inter-process communication (e.g., CGI, FastCGI >> or HTTP). > > If I understand correctly, this latter limitation is not something that > would be solved by integrating twod.wsgi into Django core. Are there any > issues or problems with twod.wsgi that would be solved by integrating it > into core?
There's a wiki article on the global state issue in Django at https://code.djangoproject.com/wiki/GlobalState but this is unlikely to be solved soon. It's something of a painful transition, because Django has built up a large ecosystem that depends on this global state. The reason is basically that it simplified implementation greatly, especially considering that Python's module/namespace system is deeply global. Frameworks like Flask have worked hard to avoid global state from the very beginning, for example Flask requires all "official extensions" to support multi-tenant applications explicitly, and recommends a pattern where WSGI applications are created by a factory function. Changing the Django ecosystem to allow for reliable multitenancy would be prohibitively disruptive. >> So, do you agree that Django should have built-in support for running >> WSGI applications from inside views? > > I'm inclined to agree with Aymeric's position on the ticket: this is a > useful feature for some scenarios, but it works just fine as a > standalone project, and I just don't see enough demand for it to justify > adding the maintenance burden for it to core. > > Carl I think this is a common (and I think correct) response to many feature requests: If there is anything in core that is blocking the external implementation of a feature like this, it's worth looking at, else just implement it outside of core. Particularly in this instance since it will still be impossible to embed Django applications anyways. Best, Alex Ogier -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
