Reusable Django mechanism for registering plugins / admin classes / signals / commands etc

[simon]

"Registration" is a general problem within Django, which is currently solved in a number of different ways in a number of different places. For example

• django.contrib.admin needs things to register with admin.site.register (but only once to avoid AlreadyRegistered exceptions) - admin.autodiscover() handles this
• Django signals should be registered once and only once - it is currently left up to the application developers how they do this
• Custom management commands should in theory be registered, but in practice they are just dropped in to a standardised directory structure which is scanned by djang.core.management.get_commands
• Likewise for custom template tags, which are currently hunted out by the {% load %} tag
• django-tagging has its own registration mechanism
• Finally, if end-users invent their own thing that requires apps to register with it (we've done that twice now on the project we are working on at GCap) they have to reinvent things yet again!

INSTALLED_APPS is used in many of the above cases - the idea being that if an application is listed in INSTALLED_APPS it should have its various things-that-need-registering registered. I propose coming up with a single, documented mechanism by which an application has all of its stuff registered - maybe a module in the applications directory called register.py that is garaunteed to be imported once and once only when the Django environment is first initialised.

This is not needed for 1.0, but would be a good problem to solve as part of 1.1.

[Malcolm Tredinnick]

With all due respect, Simon, I think it would be better to close this ticket and have the discussion on django-dev with some proper concrete code to consider. Right now it's a "we might do something" and a bit too abstract. Plus these tickets usually result in design work happening in a ticket rather than on the mailing list.

Your proposal may or may not work (it potentially throws away lazy, on-demand loading by using registering -- which implicitly requires sanity checking), but right now it's hard to tell. Common loading code wouldn't be bad idea, although making it backwards compatible could be tough.

Anyway, please consider closing and first having the basic discussion after 1.0. Then we'll have a better idea of what's possible. Right now, there's no way to resolve the ticket, except as "won't do" (which first requires a lot of design work to decide) which is a sign that it's not really ready to be a ticket.

[(none)]

Milestone post-1.0 deleted

[Collin Anderson]

​http://groups.google.com/group/django-developers/msg/93e3a08c0760f05d

[Luke Plant]

Marking WONTFIX on the basis of Malcolm's comments, and the fact that things have moved on a lot.