:date: 2017-09-20

=============================
Wednesday, September 20, 2017
=============================

Python 3 support for Appy
=========================

After a second `failure on travis
<https://travis-ci.org/lino-framework/xl/jobs/277485502>`__ 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
<https://pip.readthedocs.io/en/1.1/requirements.html>`__ file) because
it has no file :xfile:`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 :xfile:`setup.py`
file?  `Here
<https://stackoverflow.com/questions/2204811/pip-install-a-python-package-without-a-setup-py-file>`__
is a seven years old stackoverflow discussion about this.

Changed configuration API for demo_projects
===========================================

I moved the definition of :envvar:`demo_projects` from lino.invlib to
:mod:`atelier.invlib` and changed the syntax: the itema of
:envvar:`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 :xfile:`manage.py` file. Until now only the
:xfile:`settings.py` was required.
We have a new setting :envvar:`prep_command`.

Advantages: the concept of demo projects becomes more general, and the
documentation is no longer splitted but in a single place
:ref:`atelier.invlib`.


The Github threat
=================

Carl Chenet writes in `The Github threat
<https://carlchenet.com/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 :ref:`noi` and :ref:`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 <https://about.gitlab.com/features/time-tracking/>`__.  And
when I read `their strategy <https://about.gitlab.com/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 :ref:`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
:mod:`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*.