Sunday, January 10, 2016

Miscellaneous

The trick of saying python -m lino.hello to get the Lino version no longer fails when a LINO_CACHE_ROOT is set but the cache directory was used by another application.

I made an upgrade on The Lino framework in order to test yesterday’s changes (LINO_SITE_MODULE). Which tought me that the activate script of a virtualenv is not being executed by the wsgi process. So #707 itself is not yet a solution for defining site-wide configuration files on an Apache host, this remains artwork of system managers. But at least it is a solution for the problem reported by Sandeep, and it makes Lino more flexible.

Difference between fab test and per-project tests

Sandeep asked: To run belref test setup, do I need to run fab test under repositories/lino or is there a different command for belref?

Answer: Neither yes nor no.

fab test calls the full test suite of the whole Lino project. It does so even when you invoke it from a subdirectory (because Fabric searches parent directories to find its configuration file fabfile.py).

The full test suite is defined in the tests/__init__.py file. If you look at this file, you can see (among others):

class ProjectsTests(LinoTestCase):

    def test_belref(self):
        self.run_django_manage_test("lino/projects/belref")

Which means that one part of the Lino test suite is to cd to lino/projects/belref and to run python manage.py test there.

When you are working on an issue which causes the Lino test suite to fail in above part, then you won’t want to run the whole test suite again and again. It is more efficient to run:

python setup.py test -s tests.ProjectsTests.test_belref

Above command is equivalent to this one:

$ cd lino/projects/belref
$ python manage.py test

But that’s not all. You might want to run a local runserver in the belref project, point your browser to it and manually play around:

$ cd lino/projects/belref
$ python manage.py runserver

But note that you might need to initialize the demo database before it works. Here again, if you call fab initdb, then Fabric will initialize the databases of all the demo projects. You can save time by doing it only for belref:

$ cd lino/projects/belref
$ python manage.py initdb_demo

Note also that there is also another test case which uses the belref project:

class DocsTests(LinoTestCase):

    def test_belref(self):
        self.run_django_manage_test("docs/tutorials/belref")

The general recommendation is that you first get the specific test case running, and when it passes, then you run the whole suite in order to see whether some other tests got broken.