Wednesday, September 20, 2017

Python 3 support for Appy

After a second failure on travis caused by appy under Python 3, I heard good news: Gaetan is advancing with porting his appy framework to Python 3, and his work is published on https://forge.pallavi.be/projects/appy-python-3

I can easily check out a copy of the repository to my machine:

$ svn checkout https://svn.forge.pallavi.be/appy-python-3

But it seems that this repository cannot be installed (and I therefore cannot specify it in our requirements.txt file) because it has no file setup.py:

$ pip install -e svn+https://svn.forge.pallavi.be/appy-python-3/trunk#egg=appy
Obtaining appy from svn+https://svn.forge.pallavi.be/appy-python-3/trunk#egg=appy
  Checking out https://svn.forge.pallavi.be/appy-python-3/trunk to ./env/src/appy
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    IOError: [Errno 2] No such file or directory: './env/src/appy/setup.py'

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in ./env/src/appy/

Gaetan, is there any reason why you don’t have a setup.py file? Here is a seven years old stackoverflow discussion about this.

Changed configuration API for demo_projects

I moved the definition of demo_projects from lino.invlib to atelier.invlib and changed the syntax: the itema of demo_projects must now be directory names (and no longer names of Django settings modules). Yes this means that every django demo project now needs a manage.py file. Until now only the settings.py was required. We have a new setting prep_command.

Advantages: the concept of demo projects becomes more general, and the documentation is no longer splitted but in a single place inv tasks defined by atelier.

The Github threat

Carl Chenet writes in The Github threat: “Bug report builds the memory of Free Software projects. It is the entrance point for new contributors, the place to find bug reporting, requests for new functions, etc. The project history can’t be limited only to the code. It’s very common to find bug reports when you copy and paste an error message in a search engine. Not their historical importance is precious for the project itself, but also for its present and future users.”

Yes, bug reports are an important part of a project and we cannot trust on a proprietary system for storing them. That’s one of the reasons why we use Lino Noi and Jane. It is why I continue to use this blog. This blog is the history of Lino. It is written in plain text, the most maintainable format for storing information.

But it is true my blog lacks a possibility for others to contribute, that maintaining a ticketing system is a lot of work, and that using a self-made system demands a lot of motivation from new contributors. Should we move from github.com to gitlab.com or forge.pallavi.be? BTW today I also saw that gitlab has time tracking. And when I read their strategy, I ask myself “Why don’t we join them?”

Okay the gitlab time tracking does not have “start/stop” buttons and a MySessionsToday view, two Lino Noi features I would miss.

A more usable interface for bugs.saffre-rumma.net

First step is to make the “All tickets” table available to anonymous. This caused me to review the user roles of lino_xl.lib.tickets: Renamed “TicketsUser” to “Reporter”,

User roles in this module no longer inherit from any other role. That’s a general tendency: I meanwhile believe that it is better to keep the user roles atomic and let the applications group them into their user types.