flatpak-builder-tools VS shared-modules

Setting the build configuration for a module with things like type: autotools, type: cmake-ninja, or type: meson will add the necessary options automatically. Likewise, helper scripts like flatpak-pip-generator will generate manifest fragments containing the necessary prefix-specifying arguments.

There's also this pull request https://github.com/flatpak/flatpak-builder-tools/pull/347 that would add an --ignore-installed= option to flatpak-pip-generator.

Yeah, turns out I had to do something similar to this. flatpak-dotnet-generator proved pretty useful, even if the README was a bit out of date.

If you want it automated, for most packages you can use flatpak-pip-generator

The first issue I had was working out how I add PyPI packages as deps, then I was pointed towards flatpak-pip-generator which generates JSON files that you can add as modules. That works fine:

For packaging with local cache and without networking, use the flatpak-go-get-generator.py from flatpak-builder-tools. I didn't have much success recently with go-get generator, so I'm not sure if working correctly, or it's just me doing something wrong.

I am trying to install `flatpak-pip-generator` found in the link here. It looks like it is part of the `flatpak-builder` package but I have that installed and I can't seem to use the pip-generator. I run the command listed in the readme `flatpak-pip-generator --requirements-file=/the/path/to/requirements.txt --output pypi-dependencies

That one page in the docs does mention that tricky things like dependency resolution have to be done in advance, but support for building that dependency resolution is at best officially unsupported. There's a git repo dedicated to scripts to do this sort of thing but:

It would be nice to see some Crystal apps on flathub (I believe Hashbrown is the only one at the moment). A crystal sdk (like rust's) and a shard builder tool to generate the shards automatically would greatly improve the experience, if anyone is up to doing them.

You can probably use the shared-modules file for Python 2.7 as a starting point, assuming they didn't change their build process too significantly between 2.7 and 3.8.

If it's not guaranteed to be provided by the runtime (which I imagine freetype2 would be), then it's a bug and should be reported. (I submitted a fix for sdl12-compat.json not listing its dependency on GLU.)

Not sure about it, but the gimp flatpak builds gtk2 so I'm not sure if it's part of any runtime or not: https://github.com/flathub/shared-modules/blob/4c83a37cf50fa4c03ceffaf075a189031b5e8e94/gtk2/gtk2.json

There are some cases where libraries are not shared: Old libraries for example like Python 2 must be bundled with the application, so they can differ. Even then, most stock 'legacy' libraries share the same shared-modules.

Flathub has a shared module for libusb: https://github.com/flathub/shared-modules/blob/master/libusb/libusb.json