id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
8362	Reusable Django mechanism for registering plugins / admin classes / signals / commands etc	simon	nobody	"""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."	Uncategorized	closed	Core (Other)	dev	Normal	wontfix			Design decision needed	0	0	0	0	0	0