#20717 closed Cleanup/optimization (duplicate)

Generic autodiscover() mechanism

Reported by: niconoe Owned by: nobody
Component: Packaging Version: 1.5
Severity: Normal Keywords:
Cc: nicolas@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no



For an app I'm currently working on, I was looking to implement some configuration mechanism to load and execute my_app_config.py files in other installed apps directories, similar to how we configure the admin site through multiple admin.py files and by calling the admin.autodiscover() function.

It seems a quite common pattern found in many other apps (Django CMS, django-admin2, ..), but I was quite surprised to see that everyone seems to reinvent the wheel in this aspect. Shouldn't we provide a clean public-facing function (in django.utils) to do exactly this ?

If it appears that the use-cases are too different to be code-factorized, maybe we should instead improve documentation in this aspect, providing some best practices on this subject ?

Should I start working on one of these two approaches ?



Change History (1)

comment:1 Changed 20 months ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to duplicate
  • Status changed from new to closed

Although it may not seem like it, this is effectively a duplicate of #3591. That ticket has evolved over time; it's currently the placeholder for a change called the "App Refactor". One of the many upshots of the app refactor is that it will provide a place to put bootstrap logic (such as autodiscovery), and a clean way to discover all the other apps that exist.

So - I'm pretty sure everything you're describing here will be covered by app refactor.

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