20131207 (Saturday, 07 December 2013)

As another proof of concept for the new plugins concept using ad.App, I want to convert the use_extensible setting into a plugin. This got a large step further but is not finished.

I also moved the cal app from lino.modlib to lino.apps. (Which caused rather many code changes; next time I should do this in a separate branch.)

Concretely: the lino.modlib.cal app has been moved to lino.apps.cal, and the use_extensible functionality has been encapsulated into a new app lino.apps.extensible. Both apps are now plugins.

One eureka effect was when I moved get_patterns and related methods from Site to Kernel.

djangosite.djangosite_site : override_modlib_models is now a dict, no longer a simple set. Because when somethings is wrong, the error message should be able to tell me which plugin was wrong.

I wrote some more about Plugin inheritance.

I upgraded the Django of my default development environment from 1.5.1 to 1.6.0. This revealed some missing default=False on BooleanField in Lino Welfare. And it caused a new exception (TransactionManagementError: This is forbidden when an ‘atomic’ block is active) due to a hackerish method bulk_create_with_manual_ids in lino_welfare.modlib.debts.models.

fab initdb failed for belref and presto because I had removed the SITE instantiation from their settings module.


  • CalendarAction should be defined in lino.apps.extensible.models, but lino.extjs.ext_renderer currently still needs it because it handles this action very specially. We need to generalize this special handling.
  • Find a better name for lino.core.kernel.Kernel
  • What about the name for djangosite.djangosite_site.App? Wouldn’t be “Plugin” better? Answer: yes.