Flathub's recent ban on AI-using projects (see #6724) puts Lutris's
Flatpak channel at risk, and Flatpak has always been an awkward fit
anyway: Lutris is fundamentally an unsandboxed game manager that needs
to call host xrandr, 7z, fuser, wine, flatpak, mount drives, and reach
the user's whole $HOME. AppImage gives us a single-file distribution
that does none of that sandboxing.
This adds `make appimage`, which builds a self-contained AppImage in
a Docker/Podman container based on Ubuntu 22.04 (glibc 2.35, Python
3.10, GTK3, WebKit2GTK 4.1). The pipeline:
utils/appimage/build.sh — host wrapper (docker or podman)
utils/appimage/Dockerfile — build env with all GI typelibs
utils/appimage/build-in-container.sh
— assembles AppDir via linuxdeploy
+ linuxdeploy-plugin-gtk, runs
appimagetool
utils/appimage/AppRun — launcher; sources plugin-gtk hook,
sets PYTHONPATH, execs bundled
python3 with bin/lutris
Design notes worth flagging for review:
* The bundled Python is the build image's /usr/bin/python3.10 plus its
stdlib, with tkinter/test/idle stripped.
* PyGObject and dbus-python are taken from apt (python3-gi, python3-dbus)
rather than pip — both have switched to meson-python build backends
that drag in a sizeable toolchain, and the prebuilt packages link
against exactly the libgirepository/libdbus we already bundle from
the same distro.
* AppRun deliberately does NOT export LD_LIBRARY_PATH. linuxdeploy
already sets $ORIGIN-relative RPATH on every binary it deploys, and
exporting LD_LIBRARY_PATH would leak into every host subprocess —
which surfaced immediately when flatpak crashed loading our bundled
libssl 3.0 instead of the host's 3.4. The build script patchelf's
the RPATH on the manually-copied _gi.so / _dbus*.so so they still
find the bundled libgirepository without the env override.
* PATH is left intact apart from prepending $APPDIR/usr/bin, so host
tools (xrandr, 7z, wine, flatpak) still win — that's the whole
point of choosing AppImage over Flatpak here.
Output is dist/Lutris-<version>-x86_64.AppImage at ~83 MB. Smoke-tested
end-to-end on Fedora 43 Nobara: boots GUI, GPU detection, DB load,
service auth, GTK theme, and host subprocess invocations all work.
Refs #6724.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The hooks run the `mypy`, `ruff` and the check_annotation.py script to verify that python files are in a valid state.
Caveat: In order to have the hooks run on the client, the contributor must run `make dev` or `make install-hooks` in their environment at least once to install the hooks.
The hooks are initially in the `.hooks/` directory, but need to be in `.git/hooks` to run.
However due to the `.git` directory not being part of the git repo, the `.git/hooks` directory can't be under source control.
See [Customizing Git - Git Hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) page about Client-Side Hooks
fixes#6539
Python 3.14 evaluates annotations lazily (PEP 649), so unquoted
annotations like `threading.Event` work even when `threading` is only
imported under TYPE_CHECKING. On Python 3.10, these annotations are
evaluated eagerly and raise NameError at import time.
Add utils/check_annotations.py, an AST-based checker that detects
unquoted annotations referencing TYPE_CHECKING-only imports, covering
both bare names (`HTTPResponse`) and dotted access (`threading.Event`)
— the latter being a gap in ruff's FA102 rule. Wire it into `make
annotation-compat`, `make check`, and a new CI job.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Both the github workflow action and the Makefile was updated to target Python 3.10.
This is to make sure that when locally running `make check`, it matches the result of the workflow.
Fix format string errors in ru.po and tr.po that caused ValueError
on Russian locale (fixes#6423). Add msgfmt --check to CI to catch
translation errors early.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Prevents issues like #6419 where PEP 701 f-string syntax valid on
Python 3.12+ causes SyntaxError on older versions.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This was brought up by discussion in #4866 about
use of type annotations - here's how I'd handle mypy
to hopefully have it provide utility without causing
headaches.
* Split the workflow out into a reusable workflow.
* Call the release PPA workflow only on GitHub release publications.
* Call the staging PPA workflow on all GitHub release & prerelease publications.
* Clean up comments, and make them a bit more consistent.
* Add autoincrement logic to the PPA version number when the version we're building already exists on the target PPA.
* Build Lunar and Kinetic packages on Jammy since GitHub only has LTS Ubuntu runners.
- Adds a new GitHub workflow that triggers on published releases.
- Adds a supporting Bash script to facilitate the building and signing process.
- Adds a new directive to the Makefile for passing a GPG key id to the make process through environment variables.
- Updated min version check in setup.py to Python 3.6
- Updated isort config file and calls to align with v5.x
- Added init-hook for gi imports in .pylintrc to avoid invalid no-member issues
- Makefile: added lock, show-tree, bandit, black, mypy; updated test, cover, dev, isort, autopep8, check, isort-check, flake8, pylint; removed req, requirements;
- Updated .travis.yml to use poetry and make
- Added my email in AUTHORS
- Updated CONTRIBUTING.md
- Updated lint_python.yml to use poetry and make, reorganized instructions to have all install related steps first
- sorted imports: lutris, lutris-wrapper, cleanup_prefix.py and multiple files in tests dir
- Default target always builds the master branch and cleans afterwards.
- Update clean target to use to debian/clean file.
- Remove editor variable as it should be done system-wide.
- Various other changes.
Signed-off-by: Stephan Lachnit <stephanlachnit@protonmail.com>
