"Namespace AppIndicator3 not available" inside Flatpak

[androidWG]

I'm writing an app in Python and packaging it using PyInstaller. On Linux, I'd like to make a Flatpak of the app since Flatpaks can run in basically any deskop Linux distro. One of the app's dependencies is pystray, which creates a system tray icon/status indicator/app indicator. On Linux it does that primarily through libappindicator, and it depends on the PyGObject library to function.

For Linux, the build process for my app consists of building generic Linux binaries with PyInstaller, then packaging into a Flatpak along with dependencies (only dep. is libappindicator). The binaries work fully when running them outside the Flatpak sandbox, however after packaged this error appears:

Traceback (most recent call last):
  File "pystray/_appindicator.py", line 24, in <module>
  File "gi/__init__.py", line 126, in require_version
ValueError: Namespace AppIndicator3 not available

The line causing this error is this:

# pystray/_appindicator.py
gi.require_version('AppIndicator3', '0.1')

I thought this was because for whatever reason the libappindicator dependency wasn't installed correctly, and I spent a long time trying to fix that. But if I open a shell inside the app's sandbox, open a Python console and try to import AppIndicator using gi.require_version('AppIndicator3', '0.1') it gives no error. Which to me means it must be something related to PyInstaller, since AppIndicator is installed correctly on the sandbox.

I tried adding a hook to gi.repository.AppIndicator3 and making that a hidden import too but no success. Any help on this?

Repo: https://github.com/androidWG/Discord.fm (see linux branch)
Spec file: https://github.com/androidWG/Discord.fm/blob/linux/build/main.spec

[rokm]

If your Flatpak sandbox has a fully-fledged Python environment with all dependencies available, why are you using PyInstaller in the first place? You could put your program's source in the sandbox and run it in Flatpak-provided python environment.

PyInstaller is designed to create frozen applications that try to be isolated from the target run-time environment (as much as possible, anyway). The shared libraries are collected from the build system and bundled with the frozen application, so in general, libraries from the target system environment are not used - with exception of low-level libs, such as libc, DRM graphics stack, and so on.

If the sandbox fully matched the build system (especially in terms of default library search paths), then AppIndicator3 might have been picked up from the sanbox itself. For example, if I freeze the following program on my Fedora system:

# program.py
import gi
gi.require_version('AppIndicator3', '0.1')
from gi.repository import AppIndicator3
print(AppIndicator3)

pyinstaller --clean --noconfirm program.py

and run it on the same system

./dist/program/program 
<IntrospectionModule 'AppIndicator3' from '/usr/lib64/girepository-1.0/AppIndicator3-0.1.typelib'>

It finds the AppIndicator3, but takes it from the system library directory - which means that from PyInstaller's perspective, we failed to properly collect it, due to lack of hooks for it.

---

The hooks for the gi.repository stuff are a bit more complex than just adding a hidden import. You need a pre-safe-import-module hook that adds a run-time module (example) and a standard hook that collects typelib using provided utility functions (example).

So in this case:

# hooks/pre_safe_import_module/hook-gi.repository.AppIndicator3.py 
def pre_safe_import_module(api):
    api.add_runtime_module(api.module_name)

and

# hooks/hook-gi.repository.AppIndicator3.py 
from PyInstaller.utils.hooks.gi import GiModuleInfo

module_info = GiModuleInfo('AppIndicator3', '0.1')
if module_info.available:
    binaries, datas, hiddenimports = module_info.collect_typelib_data()

pyinstaller  --clean --noconfirm --additional-hooks-dir=./hooks program.py

./dist/program/program 
<IntrospectionModule 'AppIndicator3' from '[...]/dist/program/_internal/gi_typelibs/AppIndicator3-0.1.typelib'>

The typelib and its dependencies should be properly collected now.

[rokm]

See #8149 (and also #8148, which came up while I was working the above example).

[androidWG]

That's another way I tried doing it, but I ran into some other issues while trying to setup the process, so I tried doing it like this instead. I was trying back and forth from that method and this trying to get them either to work. And yeah, making the Python environment inside the Flatpak directly makes sense.

Right after I posted this, I tried making it that way and it worked out. I also tried adding the hooks you provided and it also worked using PyInstaller, though the DBus gi module was also not found inside PyInstaller's sandbox.

Thank you for the help, going forward I'll use the Python environment inside Flatpak directly method.