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

How does Django start?

Avatar for Marc Tamlyn 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

Avatar for Marc Tamlyn

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