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
$ 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/
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
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.