text: 20131227 (Friday, 27 December 2013)¶
  More on “App-loading reloaded”¶
  After discovering Aymeric’s implementation for solving the verbose_name of apps, I continue to think about what I think about it…
  I perceive it as a symptom therapy which leaves intact the “root of the evil”. But that’s the personal feeling of a revolutionary like me who lives in his own world and does not have any historic Django site to maintain.
  My djangosite approach is more powerful… but also more
  revolutionary. Especially I don’t see how we could avoid to define
  the installed apps by overriding the
  get_installed_apps of
  a Site class. And we know how conservative Django is.
  So basically everything is okay, I don’t hope to convert Django to do what Lino does. I just suggest to differentiate between “app” and “application”. We can continue to call them “apps”, but should refrain from expanding that word to “application”. Because apps are not applications, they are plugins which we happen to call “app” for historical reasons. This rule shouldn’t offend even the most conservative Django developer.
  More on djangosite¶
  I updated the djangosite documentation in the hope that other developers understand what i mean.
  get_installed_apps is now allowed to yield items which are
  generators. This makes aplication code more intuitive. Until today
  you had to write:
  def get_installed_apps(self): for a in super(Site, self).get_installed_apps(): yield a yield 'django.contrib.contenttypes' ...
  Now you can write:
  def get_installed_apps(self): yield super(Site, self).get_installed_apps() yield 'django.contrib.contenttypes' ...
  Side effects:
  - New attributes app_name and app_module for each
  Plugin.
  - Apps that do not define a “Plugin” name will now nevertheless receive a
  Plugininstance that represents them using default values.
  I removed the Site.add_site_attribute method and replaced it’s only
  usage (in
  lino.modlib.accounts) by a Plugin attribute.