Re: MongoDB waits for py3k signals from Django!
This is probably a dumb question, but what is the policy on this? RHEL for instance is just now releasing version 6, still running python2 from what I read. It will be for about 5 years from what I understand. I'm sure the Ubuntu LTS version that's supported right now will be the same. Is it django's policy not to switch to python3k until these do? Because if so, it will be half a decade until you can at least. On Nov 18, 6:32 am, James Bennett wrote: > On Thu, Nov 18, 2010 at 4:38 AM, Valery wrote: > > guys, now also all the MongoDB Python developers are waiting for your > > signals about Python 3. > > That's... a really bad idea. > > Our Python 3 migration process, at this point, is more or less > dictated by two things: > > 1. WSGI on Python 3 > 2. Distribution support > > Of the two, distro support is the big one, since many are still > shipping Python 2.5 (or even 2.4) as their standard Python, and we > can't leave those folks in the dust. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: MongoDB waits for py3k signals from Django!
On Sun, Nov 21, 2010 at 8:55 AM, hutch_burgopak wrote: > This is probably a dumb question, but what is the policy on this? We don't have a specific plan or timeline in mind. Like everything else in open source, it'll get done when enough people are willing to devote enough time (or money) to the effort. Jacob -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Deprecating ADMIN_MEDIA_PREFIX
Hi all, The special-cased handling of contrib.admin static assets in Django core is a long-time wart. Fortunately, the new static assets standard introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT settings finally allows us to begin a migration path to remove this wart. AdminMediaHandler is already on a deprecation path; the remaining piece is the ADMIN_MEDIA_PREFIX setting. After discussion with Jannis on IRC, we have a plan for deprecating ADMIN_MEDIA_PREFIX. The expectation is now that any apps' static assets should be found at STATIC_URL/appname. The idea is to introduce a check whether ADMIN_MEDIA_PREFIX is equal to STATIC_URL/admin, and if it is not, raise a (pending) deprecation warning and alert the user that in a future release of Django, the ADMIN_MEDIA_PREFIX setting will be removed, and the admin media will be assumed to be served at STATIC_URL/admin. Any objections to this plan before I put it into action? Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
contrib.sites and multitenancy
Hi all, I've recently been exploring simple multitenancy options in Django using contrib.sites, and have some thoughts on how core could make it easier. First, let me make a quick distinction between static and dynamic multitenancy. In the static case, you have a limited set of sites running on the codebase, that set changes infrequently, and it's not a problem to have separate settings files for each (which probably requires some level of additional webserver configuration for each as well). Django already supports this form just fine via contrib.sites and the SITE_ID setting. In dynamic multitenancy, the set of tenant sites changes often and should be manageable via the database with no need for additional configuration files or webserver reloads. In order to do this currently using contrib.sites, you have to stuff the request object into threadlocals and then monkeypatch contrib.sites to get the hostname from the threadlocals request and return a Site object accordingly. (This is the approach taken by Satchmo's django-threaded- multihost [1] and its fork django-multihost [2]). Having to do this makes me sad. But there's good news! Thanks to the work of Gabriel Hurley and others in r13980 [3], contrib.sites now sports a get_current_site() function that takes the request as a parameter, and this function is used throughout Django! Having access to the request gives us most of what we need; all that's lacking is a way for a project to put in place an alternative policy such as "return a Site object based on matching request.get_host() to Site.domain, rather than using settings.SITE_ID". (This is distinct from the current fallback to RequestSite if contrib.sites is not installed. RequestSite uses request.get_host(), but doesn't care what its value is, and doesn't get a corresponding Site object from the database, so it doesn't let you name the sites or limit the set of valid domains.) A few options for how such a hook could be implemented: 1) A setting, something like SITES_CURRENT_SITE="path.to.my.alternative.get_current_site_function". This is quite flexible, but Yet Another Setting. 1a) Same as above, but reuse SITE_ID; i.e. it can either be an integer, or a string path to a get_current_site function. It ends up a bit misnamed. 2) get_current_site fires a signal first thing, and listeners can return a Site object to short-circuit the default behavior. This is also fully flexible, but seems like perhaps more than is necessary. 3) get_current_site checks the request for a "site" attribute, and returns that if it exists. This allows the project to define its own site-selection logic in a middleware, and just attach the chosen Site object to the request. The issue here, I guess, could be backwards- compatibility with people who may already be annotating their requests with a "site" attribute. I'm not sure what guarantees Django offers in terms of not encroaching on namespaces which aren't specifically documented as open for user annotation, but I know annotating requests is not uncommon. Any thoughts on which option should be preferred here? Is there an even better option I've overlooked? Thanks, Carl [1] http://bitbucket.org/bkroeze/django-threaded-multihost [2] https://github.com/jaddison/django-multihost [3] http://code.djangoproject.com/changeset/13980 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Deprecating ADMIN_MEDIA_PREFIX
On 21/11/2010, at 10:52 AM, Carl Meyer wrote: > Hi all, > > The special-cased handling of contrib.admin static assets in Django > core is a long-time wart. Fortunately, the new static assets standard > introduced by contrib.staticfiles and the STATIC_URL and STATIC_ROOT > settings finally allows us to begin a migration path to remove this > wart. AdminMediaHandler is already on a deprecation path; the > remaining piece is the ADMIN_MEDIA_PREFIX setting. > > After discussion with Jannis on IRC, we have a plan for deprecating > ADMIN_MEDIA_PREFIX. The expectation is now that any apps' static > assets should be found at STATIC_URL/appname. The idea is to introduce > a check whether ADMIN_MEDIA_PREFIX is equal to STATIC_URL/admin, and > if it is not, raise a (pending) deprecation warning and alert the user > that in a future release of Django, the ADMIN_MEDIA_PREFIX setting > will be removed, and the admin media will be assumed to be served at > STATIC_URL/admin. > > Any objections to this plan before I put it into action? No objections from me. Removing the special case of Admin media is a natural thing to do now that we have a media handling framework. The only kink in the plan that I can see is the loss of flexibility in being able to deploy admin media anywhere you want, independent of other site media. However, I don't think this is a loss that should concern us. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
