Saturday, August 18, 2018

Make Lino installable using pip

Yesterday in a hangout with Hamza we continued to work on #2347. Now I will repair the test suite. I see that for the cosi3 demo project there are now estonian places missing.

I showed to Hamza what I previously had written in Install your Lino developer environment. We observed that inv prep took very long. I now realized the reason for this: the demo_bookings fixture causes many bookings, and especially if you don’t also specify the_demo_date. I changed the default demo_fixtures for Lino Così (defined in lino_cosi.lib.cosi.settings): removed demo_bookings and payments from default value because these caused inv prep to be very slow in Install your Lino developer environment.

There are three demo projects for Lino Così in the book: cosi1, cosi2 and cosi3 I now realized that my changes in these three projects were wrong. I changed the settings/demo.py files but actually their settings/__init__.py files did already define their own demo_fixtures.

Also we removed lino_xl.lib.mailbox from default lino_noi and added it manually in the team demo project. This change caused a failure in dd.plugins.linod because sequence order of installed apps has changed for lino_book.projects.team.

Backup my own data

It seems that DejaDup backup simply fails for me because it takes more than a night on my notebook. And I don’t see how I can verify whether the backup copy is complete. I turn back to good old rsync to an external usb disk. First I moved 23 GB of Kusta’s data from the Touro disk to my archive on doll. Then I adapted my ~/bin/backup2exthdd.sh file.

Abdelkader getting back

Abdelkader has been inactive for a while because he moved to Canada. Now reported that he found himself the solution for a problem on which he was stuck (and Hamza and I weren’t able to help him):

The problem is in declaration. I found the desciption of the field in lino core so i did: just put null=True:

discount=dd.QuantityField(null=True)

Yes, you must indeed decide yourself whether a field has null=True. Note that when you have null=True, you probably also want blank=True. But also note: since a QuantityField is technically a CHARFIELD, you probably should rather specify only blank=True.

At some moment in the past, Django people had to decide whether database fields in general should be nullable by default or not. They decided that database fields should not be nullable by default. I would probably have voted for the opposite. And as we can see, your case confirms it. You have been stuck by a frustrating newbie problem because of this design decision.