pyproject.toml, new build tool, improve github workflows

[sezanzeb]

closes https://github.com/sezanzeb/input-remapper/issues/1170

pip, in many cases, fails to install data files, which need to go into system paths, and instead puts them (despite them being absolute paths, and common workarounds/fixes) into /usr/lib/python3/inputremapper/usr/share/...

python3 setup.py install is deprecated. So I had to remove the existing installation shell script.

meson fails to install the module into a path that can actually be imported, and its python features require one to specify each individual file of the module.

So instead input-remapper will use a custom python solution. Hopefulls this works well enough to prevent all ModuleNotFoundErrors in the future.

Surprisingly, this is not much more code that would otherwise be required. We already had the data_files list and would need it with meson as well with more boilerplate. The python code to generate translations was already there. We (even with meson) need to figure out the correct python-package target path (see code comments). And on the upside, we have a lot of flexibility and control without having to dig into configuration, unexpected behavior and deal with any further limitations.

This PR also changes github workflows

• runs tests not as root anymore, which previously probably made them run with ubuntu-lts python3.12 every time, instead of the min and max versions
• adds ruff
• tests if the .deb build installs correctly and works

Important changes for packaging:

• setup.py is replaced with pyproject.toml now. So setup.py install cannot be used anymore
• building can be done via python3 -m install --root ./foo, which puts all files in the expected target directory structure in root. In my case, on ubuntu 25.04, the module ends up in foo/usr/lib/python3/dist-packages. It picks the best option from python3 -c "import sys; print(sys.path)" for this. If this is missing a feature to make it helpful for packaging, please let me know
• commit_hash.py is not built anymore, instead, values are inserted into installation_info.py

[sezanzeb]

TODO:

• [x] Fix ci
• [x] backup my computer
• [x] try python3 -m install --root / locally (works fine in the workflow vm already)
• [x] wait until next weekend in case something comes to mind
• [ ] Tell package maintainers about the change
• [ ] shell.nix uses setup.py
• [ ] Merge

[sezanzeb]

@SammysHP What do you think?

Short summary: Removed setup.py, tried meson but didn't like it, added custom install module that can do python3 -m install --root /

[SammysHP]

I don't have much experience with Python packaging, so can't say if it's good or not.

[sezanzeb]

Updated arch package (will need to use correct pkgver once this change is merged into main):

• python3-pip is required in makedepends
• removed build step because the install module installs directly
• removed setuptools

# Maintainer: sezanzeb [email protected]
# Contributor: Sven Karsten Greiner <[email protected]>

pkgname=input-remapper-git
_pkgname=${pkgname%-git}
pkgver=2.2.0.r105.g374dcccf
pkgrel=1
pkgdesc="A tool to change and program the mapping of your input device buttons."
arch=('any')
url="https://github.com/sezanzeb/input-remapper/"
license=('GPL-3.0-or-later')
depends=('gtk3' 'gtksourceview4' 'python-cairo' 'python-evdev' 'python-gobject' 'python-packaging' 'python-psutil' 'python-pydantic' 'python-dasbus')
optdepends=('xorg-xmodmap: symbol names matching the keyboard layout')
makedepends=('git' 'python-pip')
provides=("$_pkgname")
conflicts=("$_pkgname" 'key-mapper')
source=("$_pkgname::git+https://github.com/sezanzeb/input-remapper.git")
sha256sums=('SKIP')

pkgver() {
	cd "$srcdir/$_pkgname"
	git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g'
}

package() {
	cd "$srcdir/$_pkgname"
	python3 -m install --root $pkgdir
}

[sezanzeb]

@skitt, @alxpl Is this change ok for the debian, ubuntu and fedora packaging? Did you rely on setup.py for this?

[alxpl]

@skitt, @alxpl Is this change ok for the debian, ubuntu and fedora packaging? Did you rely on setup.py for this?

Hello @sezanzeb, At first glance everything seems in order and the dependencies are all there in Fedora. I'm afraid I am a bit swamped these weeks up to the holidays and I don't have the time to do a full package test. If you want to tag a release, go ahead and I will try to catch up as soon as possible.

[skitt]

I haven’t checked this PR specifically, but I maintain other Python projects that have switched to pyproject.toml without setup.py without difficulty, so this should be fine.