Upgrade to Pro — share decks privately, control downloads, hide ads and more …

How does Django start?

Marc Tamlyn
February 08, 2014

How does Django start?

App loading refactor - a story

A history of ticket #3591 - the infamous app loading refactor which is coming in Django 1.7

Marc Tamlyn

February 08, 2014
Tweet

More Decks by Marc Tamlyn

Other Decks in Technology

Transcript

  1. Start up - Django 1.0-1.6 • At some point, a

    model is imported • ModelBase.__new__() triggers django.db.models.loading.AppCache initialization • Reverse relations now work • Most other bits of code inspect settings.INSTALLED_APPS directly
  2. #3591 • Opened 26th February 2007 by Joseph Kocherhans •

    Django 0.96 was 23rd March 2007 • “Add support for custom app label and verbose name”
  3. 2007 • February 2007 - Design decision needed • September

    2007 - Assigned to Adrian • December 2007 - Accepted by Jacob • Various attempted patches
  4. PyCon 2008 • “The state of Django” - Adrian Holovaty

    • Serious attempt at sprints • Goals were: • Change (verbose) name • Change db_prefix • Multiple instances of app
  5. PyCon 2008 • Scope became very much about rewriting how

    django handles applications, not just adding a piece of admin functionality • class InstalledApps() • Overloading of app_label • Clear requirement for App.path
  6. 2010 • February 2010 - Design decision needed • Proposed

    for GSOC 2010 • “Medium complexity”
  7. GSOC 2010 • Arthur Koziel (mentored by Jannis) • Goals:

    • Multiple instances of apps • A way to avoid name clashes • Internationalisation of application names
  8. 2011 • Ongoing work by Arthur and Jannis • Some

    unpopular implementation details • Metaclasses for Apps • Reloadable app cache
  9. 2012 • Preston Holmes brings patch up to speed •

    Lots of conflicts • Lots of failing tests • Died out late 2012
  10. December 2013 • Timezones • Python 3 • Database transactions

    • Django Debug Toolbar 1.0 • “He also did an multi-day in-depth review and extended discussion as a technical reviewer of Two Scoops of Django 1.6” - Danny Roy Greenfeld
  11. December 2013 • Rethinking the approach • Minimal change •

    Just get some of it working • Old patches abandoned
  12. December 2013 • class Apps() • class AppConfig() • No

    models.py required • Customisable verbose name • Start up code • Customisable label and filesystem path
  13. Django 1.7 • What does it mean for you? •

    Existing projects and libraries may break • Hopefully, it’s just because you did it wrong
  14. Django 1.7 • Much stricter startup sequence • django.setup() •

    Configures settings • Imports all applications • Trying to use the app registry before it’s loaded will error “Apps not loaded”
  15. Django 1.7 • Module level code which requires the apps

    to be loaded will break (in models.py,) • Likely ugettext() - use ugettext_lazy() • Code relying on import order of models.py files may break • Code relying on “for app in INSTALLED_APPS” will break
  16. Use cases • Registering signals in my project specific app

    • Making my third party application have an internationalised name in the admin • Customising a third party application
  17. Register signals # blog.apps ! from django import apps from

    django.db.models.signals import post_save ! class BlogApp(apps.AppConfig): name = 'blog' ! def ready(self): from .models import Post from .signals import flush_cache post_save.connect(flush_cache, sender=Post)
  18. Third party apps # ponies.apps ! from django import apps

    from … import ugettext_lazy as _ ! class PonyConfig(apps.AppConfig): name = 'ponies' verbose_name = _('the stables') ! # ponies.__init__ ! default_app_config = 'ponies.apps.PonyConfig'
  19. Customising third party # myproject.apps ! from django.db.models.signals import post_save

    from ponies.apps import PonyConfig ! class MyPonyConfig(PonyConfig): name = 'ponies' def ready(self): from ponies.models import Pony from pony_util.signals import flush_cache post_save.connect(flush_cache, sender=Pony)
  20. The future? • AppAdmin - more advanced API for customising

    appearance of apps in the admin • App specific settings
  21. The future? (+ponies) • Setup time customisation of models •

    Add fields • Change field lengths • Add indexes