Monday, May 4, 2020

The Set up a Lino production server page should say more clearly that we usually don’t want to --clone on a production server. It now also explains the master environment.

getlino configure must default --shared-env to the current VIRTUAL_ENV only when --clone was given (not always). And while we’re there I think that it also must create the repos_base only then.

In the site project dir there was a symbolic link env pointing to /usr/local/lino/shared/master/. This was clearly wrong. We don’t want this production site to use any shared repositories. I did:

$ go prod
$ rm env
$ virtualenv env
$ . env/bin/activate
$ pip install lino-avanti

Oops:

ERROR: Could not find a version that satisfies the requirement openpyxl==3.0.1 (from lino->lino-xl->lino-avanti) (from versions: 1.1.0, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.2.3, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.6.1, 1.6.2, 1.7.0, 1.8.0, 1.8.1, 1.8.2, 1.8.3, 1.8.4, 1.8.5, 1.8.6, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.1.0, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.5, 2.4.0, 2.4.1, 2.4.2, 2.4.4, 2.4.5, 2.4.7, 2.4.8, 2.4.9, 2.4.10, 2.4.11, 2.5.0, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 2.5.5, 2.5.6, 2.5.7, 2.5.8, 2.5.9, 2.5.10, 2.5.11, 2.5.12, 2.5.14, 2.6.0a1, 2.6.0b1, 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.6.4)
ERROR: No matching distribution found for openpyxl==3.0.1 (from lino->lino-xl->lino-avanti)

Yes, Lino was saying openpyxl==3.0.1 as install requirements. Which was probably something old. They are at 3.0.3 now. And I guess that this version no longer exists. Removed the version requirement.

Quite disturbing because now I need to make a PyPI release for Lino and XL as well. Which means that Tonis’ and my latest work will be on their production site. Which should be avoided because they did already end-user tests.

The main reason for this embarrassing situation is that this problem wasn’t covered by the getlino test suite. So I reviewed the getlino test suite. There was quite some bullshit there!

Just in case I ran the book tests on my machine with the new openpyxl version.

En passant I removed two lino_openui5.projects from the demo_sites in book.

No problem with openpyxl, but in docs/dev/sphinx/intro.rst I got this failure

Exception: An item named 'user' is already defined in UserTypes

Hey, nice to meet you! This is the error message I didn’t manage to reproduce in #3614 (ImportError: no module named lino_vilma.lib.vilma.user_types)!

Now I have it reproducible on my machine. I started to explore it. The challenge is that the exception comes when it’s too late. Yes, there is an attribute “user” dangling around on the UserTypes class. But why?! It shouldn’t be there because we called clear(). Seems to be related to the fact that in cosi we don’t specify a name for the UserType “User”.

I am working on this file:

$ doctest docs/dev/sphinx/intro.rst`

If fails, and the debug messages are interesting.

But I am now too tired to continue on this. It was a bit too much of surprises. Johanna must wait another day. I leave everything open and push all my work in case Hamza or Tonis want to dive into this. If you find the explanation, I’ll pay you a cup of ice cream ;-)

10:21 : The ice cream goes to myself… I found the culprit (in lino_noi.lib.noi.user_types):

UserTypes.clear()
add = UserTypes.add_item
add('000', _("Anonymous"), Anonymous, 'anonymous',
    readonly=True, authenticated=False)
add('100', _("Customer"), Customer, 'customer')
add('200', _("Contributor"), Contributor, 'contributor')
add('400', _("Developer"), Developer, 'developer')
add('900', _("Administrator"), SiteAdmin, 'admin')

UserTypes.user = UserTypes.customer

Yes… this example shows what I love with the Python language: it even allows you to shoot in your knee. Should we forbid this kind of shooting in your knee? Seems that it would be difficult: my first idea, adding a __slots__ attribute, works only on class instances, not on the class objects themselves. Python says TypeError: nonempty __slots__ not supported for subtype of 'type', as they explain in this thread

I “fixed” the problem by saying that in Noi, the user type with internal name “user” is called “Customer” in the web interface. That’s no truly elegant solution, either.

A more elegant way to avoid at least above kind of knee-shooting is to add support for specifying multiple names for a choice of a choicelist. OMG, and I couldn’t help but quickly doing this as well… which caused yet another avalanche of (internal) changes.

The demo fixture of lino_book.projects.team is a usage example. It gives Marc the user type customer and doesn’t know that this is the same as user type user.

lino.modlib.users.UserType had a custom __repr__() method. I removed it. And as yet another optimization I changed the __repr__() method of lino.core.choicelists.Choice to include the plugin name. (Which caused again a few dozen of doctests to fail…)

TODO on the prod server (later):

  • go prod ; pip install lino-avanti

  • There are three config files in /etc/nginx/sites-available : remove the useless ones

  • Remove useless virtualenvs and repositories.