Adding official Flatpak support

[simonmicro]

Hi!

In the past days, I have put in the work to create a .yml for Flatpak with the required build instructions. I would really like to put in the work to integrate the metadata into the official repository, and finally submit the application as io.github.semuconsulting.PyGPSClient for Flathub.

For this I would need a bit of support, as the metadata need to be hosted within this repository and (if we really can go fancy) attempt for verification by setting up a GitHub Page. The required screenshots / videos I'm willing to provide via recordings from a geographic location of a local hackspace.

Also, some features need to be disabled / suppressed, e.g. via respecting an environment variable:

• Auto-updates & Update-Check (as the application is read-only during execution)
• ???

The most significant question would be if @semuadmin would be open for that and if I can proceed with this task in cooperation with a maintainer here 😁

[gdt]

Speaking as someone who has recently added most of the supporting python packages to pkgsrc, I would also welcome disabling of automatic updates and checking for updates. pkgsrc views any kind of phone-home as a bug and patches it out (without forming a judgement that it's malicious).

Speaking as someone who is the upstream maintainer of an unrelated non-geo package, I was not happy about dealing with the flathub scene, demandings things they want be added to my repo, and wanting me to use a github DNS name as the id. It seems like flathub is a big company with big-company like terms, and I didn't particularly wish to interact with them, or lead uers down that path. I'm not saying things were bad -- just that given the structural issues, I was not able to arrive at comfortable with zero work, so I stopped, because I'm not their employee.

[semuadmin]

What he said, basically.

Ok so I’m already dealing with Microsoft’s grip on GitHub, but they are at least the ‘devil I know’.

[razzeee]

This feels like a bit of a misunderstanding. Flathub won't force you to add things to your upstream repo, but we highly suggest it, as it will lead to a better experience for users and usually devs too.

I'm not sure why the reverse DNS is a problem, you define it once and will never have to think about it again unless you change hosting.

[simonmicro]

@gdt Thanks for providing your experience with attempting to merge an application into their registry. Nevertheless, this would be the first application I attempt to package and I'm willing to learn and go through the whole process at least once. Yes, the metadata is highly recommended to be added into the official repository (title, name, screenshots, descriptions and much more), as this enables the original app-authors to directly control those. If you guys really do not want to add these files into this repository, then packaging for Flathub is still possible, although no verification later on.

I personally would really welcome if I could deploy this software to my tablet using Flatpak soon, as it includes a GPS module and getting everything to work with pip was not-that-user-friendly. Especially future updates. Packaging for native distribution I would not prefer, as this really locks into the release-cycles of these...

[razzeee]

Verification does not depend on where the metadata lives.

[semuadmin]

Hi @simonmicro,

Happy to discuss but not clear what the practical benefit would be, either to me as the dev or end users? PyGPSClient is a pure Python package so there's no installation 'build' as such, and PyPi/pip work cross-platform whereas Flathub is purely Linux.

In terms of sandboxing, venv is already native to the Python ecosystem.

In terms of verification and attestation, the PyPi Trusted Publisher workflow does a reasonable job.

If anyone has specific issues with pip (or any of the wider environmental dependencies), raise a query in this forum and we’ll do our best to assist.

I'm wary of having a proliferation of proprietary installation mechanisms unless there's overwhelming benefit, as it adds to the maintenance overhead and means more fingers in my pie. I accommodate Conda in my other packages by popular request, but that requires minimal effort on my part.

But happy to be convinced otherwise.

[gdt]

The project i maintain has existed since the 90s, and is temporarily hosted on github as a git forge. There is no website; it's from an earlier time when that was at a university. Between increasing problems with github,and general principles, I am unwilling to use an id for the project which is within github's namespace. All that said, it's Free Software so if people want to package/distribute within the license, that's 100% ok. I am just not going to bless or agree to use an id which has github in it.

There's a larger point, which is that there are a vast number of packaging systems. There's pkgsrc which is multi-OS multi-CPU, and then there are a number of mostly OS-specific ones, FreeBSD and OpenBSD ports, homebrew, fink(still?), macports, and essentially every GNU/Linux "distribution" is a packaging system. Then there's snap and flatpack. That's all fine, but I don't see it as reasonable for each packaging system to ask the upstream to do work. Certainly requests like "please stop phoning home" are fair, as that isn't "please accomodate us". But flatpak seems to want to position itself as Important and push flatpak maintenance onto upstreams, rather than it some flatpak repo that has the extra stuff.

[razzeee]

But flatpak seems to want to position itself as Important and push flatpak maintenance onto upstreams, rather than it some flatpak repo that has the extra stuff.

that's not correct, it is the preferred way, as it's assumed, that upstreams should know how to run/package their software - and many downstream package managers break some of the functionality for better or for worse. It's the ideal in that way, but "flatpak repos that has the extra stuff" are 99% of flatpaks right now - and that won't change.

[simonmicro]

Hi,

let me address your points of concern there, maybe you are willing to reconsider...

Happy to discuss but not clear what the practical benefit would be, either to me as the dev or end users? PyGPSClient is a pure Python package so there's no installation 'build' as such, and PyPi/pip work cross-platform whereas Flathub is purely Linux.

The benefit would be to the user, that he can (likely) directly install this project using his native distribution's package manager, as most major Linux distributions are supported and have adopted Flatpak into their native ecosystem. Also, future updates can be installed automatically and does not require manual user intervention (yes, you have your update-checker and auto-call to pip already built-in)... Furthermore, I personally like to restrict applications on my system to run within sandboxes and restrict their access to network, filesystem and device to the absolute minimum (as this project does not make use of xdg-portals (adding more work to you, so fine if unsupported), the granted permissions are currently not temporary).

In terms of sandboxing, venv is already native to the Python ecosystem.

Yes. Except that if you want to use it on major distros nowadays you have to first install python3-venv and then python3-pip, activate it and then install, which is more work to get running than obtaining this project directly from your distros software-manager.

In terms of verification and attestation, the PyPi Trusted Publisher workflow does a reasonable job.

Yes. Absolutely, for that what PyPi does, they are doing a good job: Verifying that the person there is the owner of this repository, from which the source-code is taken. Flatpak aims to do one step more and does not only isolate and offline-build the application itself, but also all of its dependencies (if the packager chooses to do so (I did)).

I'm wary of having a proliferation of proprietary installation mechanisms unless there's overwhelming benefit, as it adds to the maintenance overhead and means more fingers in my pie.

Hold on, proprietary? Yes, it is a 3rd-party solution to deploy (your) software. I just want to explicitly state that Flatpak is fully open-source and their backend-infrastructure Flathub is as well (looking at you, Snap). Also, the user is free to choose it, and not forced when he explicitly uses another way of installing (looking at you, Snap). Yes, there will be more fingers within your pie, as it may attract people like me, who want to make specific modifications to it.

I am unwilling to use an id for the project which is within github's namespace

Yeah, I'm also not that happy about that. But in reality, the id shall reflect the primary point of origin for the specific package. If really required to, on Flathub one can change an id after the fact (...). But as you also stated, @gdt your project has not other space to be retrieved from, so...

That's all fine, but I don't see it as reasonable for each packaging system to ask the upstream to do work.

Yes, Flatpak does add a layer of maintenance, as the application is then just sitting on top of a pinned environment, which will need to be updated from time-to-time. What shall be located within the repo of the project is only the metadata required to represent the package within a graphical store. The build-instructions are going to be submitted against the Flathub infrastructure and are likely going to be maintained by me on the long run (I expect not to package every release, but I'll try to keep it mostly updated).

This situation is not that different to native distribution packaging, whereas the packages are being forked and patched to run better within a distros scope.

But flatpak seems to want to position itself as Important and push flatpak maintenance onto upstreams, rather than it some flatpak repo that has the extra stuff.

To be honest, I started to hate that with the more wide-spread use of Docker, as it introduced a few files (Dockerfile, docker-compose.yml, .dockerignore) into the repos root as well... Nowadays nearly every tool thinks it is necessary to place their files there as well (requirements.txt, package.lock, Cargo.lock, ...), which is also nice if the files are not human-readable - but that all is beside the point. This discussion is regarding the introduction of a metadata-description necessary for Flatpak of this package. I think, you can re-use the images of it within your own readme (or vice-versa) and control the displayed texts yourself, if it is going to be added here.

Sorry for my somewhat lengthy response, but I really wanted to reply to most of your raised points. If you do not want to go ahead with supporting adding this effort's results, please let me know. I'm sure the Flatpak-metadata can also be hosted beside the build-instructions over in the Flathub repository, limiting their use to only being available for the Flathub repository.

Thanks and have a nice Friday!

[semuadmin]

@simonmicro

As I say, happy to have the discussion but - forgive me - much of the above reads like a promotional pitch to me, including the obligatory swipe at the competition.

most major Linux distributions … have adopted Flatpak into their native ecosystem

Not sure this is actually the case. Neither Ubuntu nor Raspberry Pi OS (which probably represent >75% of my Linux user base) uses Flatpak natively. So, one way or another, the user is still required to do a CLI sudo install.

That some Linux distros exclude pip, Pil or tkinter (rarely venv) from their default Python env is undoubtedly an annoyance, which is why I strongly recommend using an official Python.org installation. I do also provide example shell scripts to address this, though these would benefit from further refinement.

Flatpak aims to do one step more and does not only isolate and offline-build the application itself, but also all of its dependencies

Again, “offline-build” what? PyGPSClient is pure Python by design.

I like to restrict applications on my system to run within sandboxes and restrict their access to network, filesystem and device to the absolute minimum

The only permissions PyGPSClient needs or uses are:

• read/write access to the (GPS) serial device
• (optionally) the ability to write to one or more folders within the user space for configs and data logging.
• (optionally) TCP socket access for NTRIP client/server functionality.
  I don’t think the vast majority of PyGPSClient Linux users have an issue with this.

I remain open to persuasion.