Monday, February 12, 2018

Improve the Lino Developers Guide

I did a series of changes to make the Lino Developers Guide more readable for beginners. As usual this also caused some internal optimizations.

I removed the obsolete alias dd.apps for dd.plugins. I moved the documentation for lino.api.dd from the source code to a prosa document.

I moved the “layout elements” from lino.modlib.extjs to to lino.core.elems. (I also plan to rename them to “widgets” soon).

I started to optimize the internal API about table handles, layouts and layout handles.

>>> import lino
>>> lino.startup('lino_book.projects.team.settings.doctests')
>>> from lino.api.doctest import *
>>> AllTickets = rt.models.tickets.AllTickets
>>> cols = AllTickets.get_handle().get_columns()
>>> lh = AllTickets.get_list_layout()
>>> lh  
<lino.core.layouts.LayoutHandle object at ...>
>>> lh.layout  
<lino.core.layouts.ColumnsLayout object at ...>
>>> lh.main
<GridElement main in lino.core.layouts.ColumnsLayout on lino_xl.lib.tickets.ui.AllTickets>

Tonis wrote the get_detail_elems() of an actor:

>>> list(AllTickets.get_detail_elems())
[<Panel general_1 in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>, <Panel more in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>]

I wrote a method get_detail_layout() which returns the layout handle itself. Maybe that’s easier to use:

>>> lh = AllTickets.get_detail_layout()
>>> lh  
<lino.core.layouts.LayoutHandle object at ...>
>>> lh.layout  
<lino_noi.lib.tickets.models.TicketDetail object at ...>
>>> lh.main
<TabPanel main in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>
>>> list(lh.main.elements)
[<Panel general_1 in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>, <Panel more in lino_noi.lib.tickets.models.TicketDetail on lino_xl.lib.tickets.ui.Tickets>]

The lino_book.projects.events is the only use case (in The Lino Book, one other case is in Lino Welfare) for dynamic table handles. The project was unused and ratherbroken. Now it is usable with runserver and has a test suite which covers that special use of a table with a meth:get_handle_name method.

But all this is –as usual– not finished. Tomorrow I will maybe continue.

Sphinx 1.7.0 is out

Komiya Takeshi released the newest version of Sphinx. I installed it and ran inv clean and inv bd on all my projects. No problems.

Except maybe for a SphinxWarning Inline interpreted text or phrase reference start-string without end-string". I had to temporarily set tolerate_sphinx_warnings to True in order to see where it comes from. It was in the docstring for lino.core.fields.ForeignKey(). I worked around this by removing the link to Django docs there. It is possible that Sphinx autosummary has a modified behaviour when extracting the first sentence of the docstring. But another possible explanation is that I changed this docstring recently. No need to investigate AFAICS.

Is POD ready for python 3 ?

Ajit reported a problem when trying our distribution of appy.pod. And indeed I can reproduce his problem. Here is the script which creates a file from a simple template:

.. literalinclude:: 0212/0212.py

The output document created with our version of appypod says:

Error while evaluating expression "I". 'int' object is not iterable
if escape: result.dumpContent(res)
File "/appypod/appy/pod/buffers.py", line 196, in dumpContent
nsText=self.env.namespaces[self.env.NS_TEXT])
File "/appypod/appy/xml/__init__.py", line 65, in escapeXml
for c in s:
TypeError: 'int' object is not iterable

This seems to show that appy-python-3 was not ready for Python 3 when I forked it some months ago.

Now I updated my copy of that repository:

(py27) luc@doll:~/repositories/appy-python-3$ svn update
Updating '.':
A    trunk/ui/navigate.py
U    trunk/ui/utils.py
U    trunk/ui/css.py
U    trunk/http/client.py
U    trunk/model/fields/group.py
U    trunk/model/fields/__init__.py
U    trunk/model/fields/search.py
U    trunk/model/fields/string.py
U    trunk/model/fields/calendar.py
U    trunk/model/fields/workflow.py
U    trunk/model/fields/ref.py
U    trunk/model/fields/action.py
U    trunk/model/fields/date.py
U    trunk/model/fields/file.py
U    trunk/model/fields/computed.py
U    trunk/model/fields/pod.py
U    trunk/utils/path.py
U    trunk/xml/__init__.py
U    trunk/pod/renderer.py
U    trunk/pod/converter.py
U    trunk/pod/doc_importers.py
U    trunk/pod/styles_manager.py
U    trunk/pod/xhtml2odt.py
U    trunk/px/parser.py
U    trunk/px/__init__.py
Updated to revision 123.

So Gaetan continues developing in appy-python-3 but refuses to add a setup.py file so that normal people can use the package. Furthermore I have no idea whether he saw my fixes for the trivial errors I added to his code after the fork. Oh my God, this situation makes no sense! I want to help Gaetan to make appy work under Python 3, I don’t want to fork it definitively! Gaetan, let’s meet and collaborate!