20130712 (Friday, 12 July 2013)

Even more app inheritance

I understood the necessity of even more inter-app stuff. Removed dd.extends_app and replaced it by a new module lino.ad.

Usage:

For example if you write an app myproject.courses which extends (inherits from) lino.modlib.courses, then you write in your app’s __init__.py:

from lino import ad

class App(ad.App):

    extends = 'lino.modlib.trading'

And in your app’s models.py:

from lino.modlib.trading.models import *

This works because we add a new convention:

Lino requires the modules specified in INSTALLED_APPS (not their .models modules) to be importable while Django’s settings are being loaded. Or in other words: these modules may not do from django.conf import settings.

Inheriting fixtures

Lino cannot give you a method to automatically inherit fixture directories. That’s because we would have to add them to FIXTURE_DIRS, and this would cause an unexpected loading order. Django’s will always load first fixtures of INSTALLED_APPS and only then those in FIXTURE_DIRS.

So if you want the fixtures of your parent app to load also for your child app, then you need to do this explicitly for each fixture by creating a fixtures dir in the child app, with an empty __init__.py and one .py file for each fixture. Usually this will be at least a file demo.py:

from <parent_app>.fixtures.demo import *

TODO: More plans

The lino.ad idea opens doors for new possibilities:

• lino.ad.App.verbose_name

• lino.ad.App.depends

Lino-Faggio

The test suite didn’t detect a simple failure to load the demo fixture although there was a corresponding test case with fixtures in lino_faggio/tests/faggio_tests.py. The pitfall was that such a test case must have at least one method whose name starts with “test” in order to run.