Opened 10 years ago

Closed 7 years ago

#8362 closed Uncategorized (wontfix)

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

Reported by: simon Owned by: nobody
Component: Core (Other) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX:


"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 (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
  • 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 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.

Change History (4)

comment:1 Changed 10 years ago by Malcolm Tredinnick

Triage Stage: UnreviewedDesign decision needed

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.

comment:2 Changed 9 years ago by (none)

milestone: post-1.0

Milestone post-1.0 deleted

comment:4 Changed 7 years ago by Luke Plant

Easy pickings: unset
Resolution: wontfix
Severity: Normal
Status: newclosed
Type: Uncategorized

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

Note: See TracTickets for help on using tickets.
Back to Top