flatpak-builder-tools VS net.sourceforge.tomatoes.IHaveNoTomatoes

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.

...and, for the record, I'm the maintainer of the net.sourceforge.tomatoes.IHaveNoTomatoes Flatpak and I did the legwork to get the io.sourceforge.pysolfc.PySolFC Flatpak published before handing it off to PySolFC upstream to maintain (among other things, those PySolFC screenshots were taken on the computer I'm typing on right now), so I think I know a non-zero amount about how this stuff works.

Your Appstream XML and .desktop file are unsatisfyingly sparse. (Compare the ones from the aforementioned I Have No Tomatoes flatpak that I maintain.)