Friday, August 3, 2018

I couldn’t restrain from fiddlling in the docs (ana: Analytical accounting and accounting: General accounting).

Hangout with Hamza

Pronounciation:

  • [paipi] : PyPI : Python Package Index

  • [pip] : pip Python Installer

Hamza told me that also the test pypi requires a new release number each time. Which might become irritating because we might have lots of pseudo releases when we start doing official releases.

Okay, we use a month-based version numbering (18.8.0 in August 2018), and the minor version can go as high as needed. We might add a command-line option --test to inv release.

But a better solution is to use our own server as a personalized version of PyPI that has the particularity of permitting the files to change without changing the version number:

We tested this together. It didn’t work out of the box, I had to do some minor changes in atelier (see Changes in atelier, rstgen and sphinxfeed).

Now we must document how we did this. Here is what I explained to Hamza:

I changed the sdist_dir in my ~/.invoke.py from '/home/luc/work/book/docs/dl' to '/home/luc/work/book/docs/dl/{prj}'.

So when I run pp inv sdist, it will build a zip file of style project-18.8.x.tar.gz for every project.

So we use twine only when test_sdist has passed for all projects

It seems that we need to split the developer’s guide : one for core developers and one for application developers.

  • /docs/dev : Core Developer’s Guide

  • /docs/appdev : Application Developer’s Guide

For example the “Diving into Lino” and “Getting aquaintaned” sections are for application developers.

Misc optimizations in Lino Noi

It started with two little changes I wanted to do for Jane:

  • TicketsToTriage : replace topic by site

  • Certain state transitions are now allowed only when the ticket has a site

En passant I did this:

  • I removed projects from demo fixture and replaced the series of ugly “Ticket 1” ticket summaries to a cycling of more textual summaries. Of course there were some doctest failures afterwards.

Then I decided to also attack this one:

The lino_xl.lib.working.working.WorkedHours table was being displayed in the dashboard, but clicking the ⏏ button causes an error Uncaught TypeError: Cannot read property 'grid' of undefined in the JavaScript console.

I added working.WorkedHours as a menu item to the user menu, with the same result.

I noticed that it is a VentilatingTable. And that js_render_window_action() was never called for this. And then I found the explanation: VirtualTables weren’t registered correctly. I added some text and code snippets in Introduction to actors while exploring this. And then I had an inspiration about who to reorganize this part of the Lino startup which was really very chaotic. Now it is more clear, and it’s documented and tested in Introduction to actors. Nice! Lino has become more beautiful!

I noticed that the ui5 demo project used the database of the team project. But it adds lino_xl.lib.stars. So there is one model more. That’s caused the Lino Noi database structure test to fail depending on where inv prep had been done last (because ContentTypes contained sometimes 57 sometimes 66 rows.

Split the Developer’s Guide

This morning Hamza and I realized that we need to split the developer’s guide: one for core developers and one for application developers. My first suggestion this morning was:

  • /docs/dev : Core Developer’s Guide

  • /docs/appdev : Application Developer’s Guide

But after thinking at it I now think that we can simply convert the existing User’s Guide into that guide for application developers. After all they are users of Lino. And a guide for end-users is anyway something impossible (such documentation must be done per application, not for the framework).

I quickly did this and published my first draft. I like it, the whole idea seems correct, but of cours it needs revision because the user’s guide should no longer expect people to have a clone of the Developer Guide installed.