On Wed, 2008-09-10 at 13:56 -0700, Simon Willison wrote: > On Sep 10, 9:18 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> > wrote: > > Oh, please, no! Registration is a very fragile process. It simply > > doesn't work very well. It's a bit disappointing that it's the way we > > have to do things that way in places in Django and if we can avoid it > > elsewhere that'd be nice. > > I was hoping we could get a discussion going about this at DjangoCon. > Registration is a pattern that comes up /all the time/ in Django:
*sigh* Whilst I realise you are very enthusiastic about getting stuff done at the moment, Simon. It's very hard to juggle 10 different serious design issues all at once. And, yes, I understand that some of them overlap, but solving the registration issue isn't really going to be the main part (or even necessarily any part) of working out a multiple database API. Incremental steps, rather than a plan which requires changing 6 things at once is really preferable here. It helps code stability and means we can devote our full attention to just one or two things at a time. The things you are bringing up are serious issues, but they're not new issues -- hardly anything that people are suddenly rediscovering from djangocon haven't been on our radar for months or years. We don't have to solve them all this week. So, please. Let's slow down a bit and have the time to consider how we can do things in small steps and require large sweeping changes as an "if all else fails" fallback. We might still end up using some kind of new "registration" alternative in, say, database connection registration, but that can be phase two or phase three. Phase one being the manual configuration option. > > * Registering models with the admin > * Registering models with databrowse > * Registering template tags > * Registering custom management commands You don't register custom management commands. They are "discovered", similar to import discovering modules to import: by putting them in a well-defined location. I'm not sure why template tags aren't done the same way (a distinguished variable in a file that is imported saying "these are the methods that are the tags I'm supply", similar to __all__). As I note below, the current uses of registration aren't all necessary. > It's also present in popular party apps: > > * django-tagging and django-mptt both register models (though both > feel like they should really be some kind of mixin) > > We'll also need it in the near future for a couple of in-development > features: > > * Registering custom panels with the Django debugging toolbar > * Registering new benchmarks with the metronome profiling tool > * Registering get_connection overrides in the above multi-db proposal > > Finally, we've been needing to solve it for projects at work: we have > a CMS that exposes a concept of "custom rows" which can be provided by > applications and dropped in to various places around the site. Guess > what: the rows need to be registered! > > There MUST be a good way of doing this. zope.interface? > setuptools > entry points? Whilst I realise that some people want to use setuptools, anything that *requires* it is going to be a big problem for me, at least. It has some problems that mean it's really unusable in large sysadmin installations and it acts as odds to the existing packaging system on proper distributions (you can't be a proper distribution without a proper packaging system, after all). The maintainer of setuptools has pretty clearly indicated he isn't interested in fixing the latter problem (look back at some of the interactions with the Debian guys in the past) and the former is barely acknowledged as even a problem. > We really, really need to solve this for Django. It's not entirely clear that we do, since before you solve something there has to be a problem. We could make things a bit easier, but it's quite possibly a case of using the wrong shovel to hammer in your screws in some cases and in other cases it requires almost no infrastructure. For those already firing up their replies, note that I carefully wrote "possibly". I'm asking that people step back and view the issue as whether it's the right approach before we make a better version of thing X. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
