Tuesday, December 11, 2018

Why we do Lino

#2578 (Lino versus Tryton)

When I look at our new collaboration directives and how much work I invested into these things during the last months, I cannot refrain from asking: why am I doing this work? Why don’t we join the Tryton community and give up Lino? Tryton is so similar to Lino (at least for deciders). Both in Python, both Free. Am I re-inventing the wheel?

Yesterday I was on a local village meeting. They talked about a seminar on project management they had last year (I missed that one). One participant said “The only interesting thing I learned was the rule “Give 20% to the how and 80% to the why!” I have invested 2 months into how Lino will continue to live, and my only answer (so far) to the potential question Why is “my feeling said, 5 years ago, that Lino is a bit better than Tryton”…

I asked this question already several years ago and at that moment my conclusion was: in order to answer this question, somebody would need to write a Tryton application which has a chance to become a replacement for one of the existing production Lino applications. And I am probably not the right person to do this test because I might not be neutral. But I could ask Hamza or Tonis to do it: Get started with Tryton and try to write a Lino Noi. And then give us some serious reasons for Lino to exist next to Tryton.

I read a 3 year old discussion Tryton vs Odoo on the now readonly tryton mailing list. It explains why Odoo is not even a candidate because it is not free.

I had a hangout with Hamza about this topic. Our summary is simple: We do Lino because we don’t believe that Tryton can replace Lino. Tryton is just a big application with plugins while Lino is a framework. We know that we don’t know* it, we just believe it. It would take months of research work to demonstrate this. In case you don’t believe us, then you can potentially get the whole Lino team join the Tryton project by configuring a Tryton site in a way that it has a chance to replace Lino Presto or any other production Lino application of your choice.

Lino road map December 2018

We had a look at jetadmin. A fundamental difference : jetadmin lets the end-user do very much configuration: design the application menu, layouts of tables and detail views etc. While this might look tempting for a customer, I believe that this approach is actually an anti-feature. This work should be done by a professional application developer using Python code and with reusability in mind. Providing it as a feature might be convenient in certain edge cases to provide quick customizations, but such customizations aren’t reusable. It causes analysis work to be done at the wrong place.

Build failing because of make_demo_picture

#2741.

https://travis-ci.org/lino-framework/book/jobs/466186410

Yes, the lino_xl.lib.beid.BeIdCardHolder.make_demo_picture() method is a strange thing. We have it because the welfare test suite requires some examples in the demo database that simulate clients having their Belgian eID card read into Lino. So these clients need a “real” picture. To simulate a “real” picture read from an eid card we have these files luc.jpg and ly.jpg. These need to be copied to the (local) directory for pictures uploaded from id cards. get_image_path

So the problem has to do with the include_package_data option. Maybe simply remove the zip_safe=False.

And ta-daa, only yesterday I thought that lino and lino_xl can have a common set of release notes, and already now we have a case that proves my assumption as wrong: we need a new PyPI version for XL but not for Lino.

We can either

  • do an artificial release 18.12.0 (without any change) for Lino as well

  • start maintaining separate release notes for Lino and XL

  • decide that we don’t yet want release notes for XL and restore the -e option for lino_xl in the book requirements

Since I don’t yet know the answer to above questions, for now I did a PyPI release for XL 18.12.0 without mentioning it in the release notes. And then restarted the book build on Travis. Let’s see what it does before talking more.

The problem remains, so removing the zip_safe=False was not enough.

Technical roadmap for Lino

Some research projects and missing features

  • get the cms demo project to run : After signing in, extjs interface is broken. Some menu items cause a JS error Uncaught TypeError: types[(config.xtype || defaultType)] is not a constructor. Or http://127.0.0.1:8000/ext says Page not found (404).

  • work on the bs3 ui for team so that we can log in and use it from our mobile devices to do certain actions like writing comments and assigning tickets to somebody. Add inline editing to bugs.SR (inspired by django-front)

  • a django-admin command which generates one Django permission for every user role and one Django user group for every Lino user type. And then demonstrate how Lino plugins can be combined with plain Django applications.

OTOH these projects must remain low priority as long as we have enough work on projects with immediate benefit:

  • (Tonis) Continue the react user interface

  • (Hamza) Migrate Jane to Python 3 and Django 2 (there is at least one dependency problem for channels)

  • (all) Continue to optimize the existing extjs interface

  • (Luc & Thierry) Continue to optimize Lino Noi for our own usage

  • (all) Continue to optimize the release and deployment process and developer documentation

Optimizations in Jane

  • I removed the summary view from TicketBySite and MyTicketsToWork

  • I removed the summary fields per TicketState

  • Every ticket is now a summary and holds a sum of the worked time (per reporting type)

  • lino.modlib.summaries has a new kind of summary: a BaseSummary. This is inherited by working.Workable and adds the lightning button top the ticket and makes the summary fields get updated during computesummaries.