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 cosi_ee demo project there are now estonian places missing.
I showed to Hamza what I previously had written in
Installing a Lino developer environment. We observed that
inv prep took very long.
I now realized the reason for this: the
causes many bookings, and especially if you don’t also specify
the_demo_date. I changed
for Lino Così (defined in
removed demo_bookings and payments from default value because
inv prep to be very slow in Installing a Lino developer environment.
There are three demo
projects for Lino Così in the book: apc, pierre and cosi_ee I now
realized that my changes in these three projects were wrong. I changed
settings/demo.py files but actually their
settings/__init__.py files did already define their own
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 The Lino Daemon because sequence order of installed apps
has changed for
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
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.