After waf ?

[ederag]

There are issues with the current installation system (waf): #309, #221, #252, ...

The current well established standard is setuptools. We could use thesetup.cfg configuration file.
Here is an example.
This seems to be the safest course (stability is important for this repository).

[matthijskooijman]

I'm surveying what the current waf script does exactly, other than building and installing the python module. I've identified:

• Install a dbus service file (in order to autostart the hamster daemon)
• Install top-level service script (in /usr/lib/hamster-time-tracker I believe) for dbus to start
• Install bash completion files
• Postprocess gconf schemas using gconftool-2 --install-schema-file (schemas are installed by data/wscript).
• Postprocess icons using gtk-update-icon-cache -q -f -t (icons are installed by data/wscript).
• (through po/wscript) install translations (I think)
• (through data/wscript) install various data files (images, gtk ui files, hamster.db, report template) into /usr/share/hamster-time-tracker.
• (through data/wscript) install icons into /usr/share/hamster-time-tracker.
• (through data/wscript) translate and install gconf schemas into /etc/gconf/schemas (I think).
• (through data/wscript) translate and install .desktop files into /usr/share/applications.
• (through help/wscript) install help files into (I think) /usr/share/gnome/help/hamster-time-tracker (and some more stuff I didn't immediately understand)

This is a lot more than a default python package usually does. Before making this list, I was hoping to limit what needs to happen so we could be more like a plain python package that can just be pip installed (e.g. by removing the dbus autostart, which might be a good idea anyway, but seeing this list I doubt that that is actually possible (and we'd have to rely on OS packages anyway). That does not mean we cannot use setuptools or something similar, though (I expect setuptools or other build systems can be made to do the above as well).

There has also been some movement in the python packaging area recently, with the acceptance of PEP-517 and PEP-518 that introduce a new pyproject.toml file (to somewhat replace setup.py and setup.cfg). These PEPs specify a standardized way to specify build-time dependencies and specify what build system to use (so no longer always assuming setuptools and setup.py`). If we're not aiming to be pip-installable, this does not really matter much (we can just pick any build system and call it explicitly), but this does mean there are a few new and improved build systems that we can pick from (I've looked at poetry and flit before, not really in depth though).

I'm planning to dig in a bit deeper into the above list, see if there's things that could be made unnecessary or perhaps be implemented more cleany. I'm also planning to dig into various build systems a bit more, but if there's no strong arguments for any, just a default setuptools setup is probably fine.

[ederag]

Thanks for the interesting analysis. This is way beyond my current knowledge.
@mwilck delved into the hamster waf stuff, and will probably be able to help a lot.
About the dbus autostart, is it really an issue without any hamster service launched at boot time ?

[mwilck]

@ederag, thanks, but I just made two very simple modifications. I am totally not a waf, or python packaging, expert.

[ederag]

As noted by @GeraldJansen, python2.7 end-of-life is planned at the beginnning of next year.
Without python2 our waf will cease to function. And 2to3 was not enough.
I could upload my "waf_2to3" branch if anybody is interested,
but it does not look good at all;
better spend time on the migration to setuptools (unless a much better tool is found).
@matthijskooijman what's your status on this ?

[GeraldJansen]

Maybe we could just copy the setup from https://github.com/gtimelog/gtimelog? Looks pretty simple to get pip3 installation set up (and in the Makefile there is even a flatpak setup and installer).

[ederag]

As @matthijskooijman pointed out, the build process is rather complex.
After looking at setuptools, it appears that some of the waf functionality
would have to be reinvented (e.g. for internationalization).
So I gave another try to waf, this time starting with the last version and reading the documentation.
Looks good so far.

[ederag]

Good news. Installation goes smoothly on a fresh ubuntu-19.04, help pages excepted for now.
Need polish before PR.

[GeraldJansen]

I would like to suggest releasing v2.3 as hamster v3.0: completely python3 + gtk3 (yay!). It would give the message that the project is alive and kicking (well at least stumbling forward) and would clarify the confusion concerning v2.x versus hamster-applet v2.91.3 once and for all.

[ederag]

#421 has been merged, it has been tested successfully
on openSUSE Leap 15.1, ubuntu 18.04 and 19.04.

For packagers

In an rpm package, the installation instructions would be updated to

%build
# new --gconf-dir option
./waf configure build --gconf-dir=%{_sysconfdir}/gconf --prefix=%{_prefix} configure build
%install
# no change here
./waf install --destdir=%{buildroot} --libdir=%{_libdir} --libexecdir=%{_libexecdir}

The --gconf-dir added in commit 9a157c0 should ensure a cleaner installation.
Changes to dependencies can be seen in the README diff

Please ask if anything is not clear. Being back in distributions is important for this project IMO.

[ederag]

@matthijskooijman please let me thank you again;
it is your extensive analysis that brought me back on the waf track,
because other distribution systems did not seem capable of doing so much stuff out-of-the-box.
Thanks to the waf developers, great tool !
And thanks to @GeraldJansen for the continuous and relevant feedback.

[matthijskooijman]

Given that waf is somewhat discouraged within Debian (which is probably sufficiently solved by #569 for hamster, though), I did wonder how other python-based applications and Debian packages for them handle building and installing additional files. I found two examples, both of which use normal setuptools and the data_files entry to install extra files in arbitrary filesystem locations. They also both run extra custom code on build/install/test/etc. for additional setup actions (though I think terminator does it nicer using cmdclass, whereas fail2ban just peeks at sys.argv):

• https://salsa.debian.org/python-team/applications/terminator/blob/debian/master/setup.py
• https://salsa.debian.org/python-team/applications/fail2ban/blob/master/setup.py

Just in case we might want to move away from waf after all later, I thought it would be good to keep these links here for reference.