Wednesday, August 17, 2016

#1115 (Support Django 1.10)

I accepted Hamza’s pull requests for Lino and Book and then reviewed his work.

Yes, initdb and initdb_demo were still using some obsolete features. I continued to convert them, e.g. the class attributes args and help are now obsolete. There is some hassle with the handling of positional arguments.

About The Lino Polls tutorial: Hamza correctly noted that I forgot to adapt the demo1.py fixture when I worked on that tutorial last week. He then correctly decided that the problem went undetected because that fixture was never loaded during automatd tests. And your solution to set demo_fixtures = ['demo', 'demo1'] indeed caused the problem to be covered. But it introduced another problem: the questions were loaded twice.

I fixed these problems by adding a series of invisible code snippets into the index.rst file.

The construct

>>> from django.core.management import call_command
>>> call_command('initdb', 'demo', interactive=False)

also seems to have some problem with the handling of positional arguments. Furthermore it is rather obsolete because we now have:

>>> from atelier.sheller import Sheller
>>> shell = Sheller()
>>> shell("python manage.py initdb demo --noinput -v 0")

Using the sheller is better here because it reflects reality more accurately and because it also covers the shell’s command-line parsing.

One difficulty was that I want to run these invisible code snippets with –verbosity set to 0 because the output of these commands is not relevant here (an rt.show(‘polls.Questions’) afterwards is a better test), and that lino.utils.dpy logged two messages (“Loading %s…” and “Loaded %d objects”) even when verbosity was 0. I removed these two messages.

Miscellaneous

Yesterday I tidied up in atelier and removed Project.load_fabfile. Now I fixed a regression in the per_project

ImportError: No module named metaphone.word

The online demo of Lino Welfare reported a ImportError: No module named metaphone.word.

First assumption: I thought yes, indeed, when I did did the upgrade there some days ago, (i.e. git pull in all repositories), I did not consider the fact that Lino Welfare has a changed install_requires. The following doesn’t output anything in that environment:

$ pip freeze | grep meta

I didn’t even try to fix the problem by saying pip install metafone because I wanted more: I wanted to avoid similar problems in similar future situations. What we would need is a general way of telling pip to update the dependencies of an editable package. I tried the following:

$ pip install -U lino-welfare
Collecting lino-welfare
  Downloading lino-welfare-1.1.25.tar.gz (3.8MB)
    100% |████████████████████████████████| 3.8MB 147kB/s
^COperation cancelled by user

No, that’s now what we want. And I would even say that this is a strange behaviour of pip. Okay my request is a bit odd, I ask it to upgrade a package which is installed in editable mode.

I tried this:

$ pip install -U -e lino-welfare/
Obtaining file:///home/luc/repositories/lino-welfare
Collecting lino_cosi (from lino-welfare==1.1.26)
  Downloading lino-cosi-0.0.2.tar.gz (3.0MB)
    100% |████████████████████████████████| 3.0MB 189kB/s
Collecting vobject (from lino-welfare==1.1.26)
  Downloading vobject-0.9.2.tar.gz (50kB)
    100% |████████████████████████████████| 51kB 4.0MB/s
Requirement already up-to-date: django-iban in /usr/local/pythonenv/demo/lib/python2.7/site-packages (from lino-welfare==1.1.26)
Requirement already up-to-date: metafone in /usr/local/pythonenv/demo/lib/python2.7/site-packages (from lino-welfare==1.1.26)
Requirement already up-to-date: weasyprint in /usr/local/pythonenv/demo/lib/python2.7/site-packages (from lino-welfare==1.1.26)
Requirement already up-to-date: cairocffi<0.7 in /usr/local/pythonenv/demo/lib/python2.7/site-packages (from lino-welfare==1.1.26)
Requirement already up-to-date: suds in /usr/local/pythonenv/demo/lib/python2.7/site-packages (from lino-welfare==1.1.26)
Collecting lino (from lino_cosi->lino-welfare==1.1.26)
  Downloading lino-1.7.5.tar.gz (10.5MB)
    100% |████████████████████████████████| 10.5MB 55kB/s
^COperation cancelled by user

This either isn’t what we need because it ignores the fact that cosi, lina and xl are equally in editable mode and therefore should not get updated.

But all above was rather useless. Yes it is a little problem that pip cannot upgrade the dependencies of editable packages. But I had that error message immediately after upgrade during initdb_demo, and I actually did pip install metafone at that moment.

If I had tried to fix the problem by saying pip install metafone, I would have noticed that it actually was installed. When using pip freeze and grep to see whether a package is installed, you should always add the -i option to grep:

$ pip freeze | grep -i meta
Metafone==0.5

The explanation for our problem was in a completely different direction. It was because the metaphone directory in the site-packages directory of the virtualenv had been created with the wrong group. I guess that I didn’t yet have all File permissions problems fixed on The Lino framework when I installed metafone. As a result, Apache was not able to import it.

En passant:

  • I removed a useless code line “from metaphone.word import Word” in lino.mixins.dupable

  • I removed the .encode(‘utf8’) from dm = fuzzy.doublemetaphone(s.encode(‘utf8’)) because this was necessary only with fuzzy. (Or I hope so… at least the test suite did not fail after removing it).