I’ve ported caffeine-ng to use meson rather than python-wheel for building and installing. Python’s packaging ecosystem is moving in a direction that will only support python packages, but not packages that need to install data files outside python’s package location. This last scenario is deprecated and will become unsupported in future. It already doesn’t work when using python wheels, as discussed on that issue.
caffeine-ng, like many other desktop applications, ships with data files including manual pages, desktop entry files, icons, translations, etc. It’s clear that Python’s build / packaging ecosystem has difference goals in mind and isn’t a good fit here. This isn’t a big deal though: tools for building and installing projects like this already exist.
While it is still possible to distribute a python package that ships data files in arbitrary locations (e.g.: man pages), it is (and always has been) somewhat ugly and hacky. The project maintainer needs to write the setup script that manually copies all the files to the right paths, and then write the application code to find such files at runtime. Given that Python packages can be installed into a virtualenv, this becomes even more of a pain.
caffeine-ng itself also has multiple non-python dependencies. There’s no way for a python package/wheel to announce these; it can only raise an exception, and hope that the user (or packager) knows how to figure that out. There’s no escape hatch for this, so it seems that shipping via this particular distribution mechanism isn’t ideal for us.
Meson
Meanwhile, meson is a much better fit. It can deal with installing a Python
module, but also has explicit support for man pages, building translations, and
all the other functionality needed here. It’s also widely used for projects in
a variety of languages, so distribution packagers will usually be more
familiar. It also makes installation easier for end users, since they don’t
need to worry about pip and other Python-specific tools that don’t really
target end-users.
Something that I appreciate greatly, is that uninstalling also works well
by just using ninja -C build uninstall.
When working on a project, uninstalling via meson will remove files that it
previously installed if the new project build removes references to that file.
It’s always nice to keep things nice and clean, and this was never fun with
old-school Makefiles.
Finally, because meson is not Python-specific, it can verify that non-Python dependencies are installed and at compatible versions – something entirely out-of-scope for Python packages.
Porting this project to meson took a few hours, but most of the time sink was due to my having to familiarise myself with it. Similar future endeavours will definitely take far less. If you’re interested in learning a bit of what meson looks like and what it can do, I encourage you to take a look at caffeine-ng’s meson.build file; it’s a rather complete example (with all sorts of data files), though likely not the most refined one.