:date: 2018-08-18

=========================
Saturday, August 18, 2018
=========================

Make Lino installable using pip
===============================

Yesterday in a hangout with Hamza we continued to work on
:ticket:`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
:ref:`user.install`.  We observed that :cmd:`inv prep` took very long.
I now realized the reason for this: the :mod:`demo_bookings` fixture
causes many bookings, and especially if you don't also specify
:attr:`the_demo_date <lino.core.site.Site.the_demo_date>`.  I changed
the default :attr:`demo_fixtures <lino.core.site.Site.demo_fixtures>`
for :ref:`cosi` (defined in :mod:`lino_cosi.lib.cosi.settings`):
removed `demo_bookings` and `payments` from default value because
these caused :cmd:`inv prep` to be very slow in :ref:`user.install`.

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

Also we removed :mod:`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 :mod:`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
:file:`~/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.