On Mon, Apr 13, 2020 at 6:53 PM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > So with Python 2 being fully removed (more or less) with Fedora 32, Fedora 31 is the last version that will contain Chirp, which is an important and the ONLY tool for Amateur Radio operators to program radios in linux. > > Don't get me started on upstreams lack of interest on correcting the issue... > > So I decided to look at flatpaks as a method of making it available post Fedora 31. > > 1. The documentation sucks. You see code snippets everywhere and it's not clear what section it belongs in the json file, which leads me to #2. > > 2. JSON may be fine for machine readability but it SUCKS for human readability. Both brackets and braces! Do I need a "," after that one? All I know is I screw around with it until vim doesn't show me any more red highlights. > > Yes, you can do YAML instead, which is FAR more readable, but MOST of the examples are in JSON. > > 3. I understand the names (app-id) need to be unique, but how about some better guidance on how to name them! > > 4. Examples show you how to execute "pip..." to install python dependencies, but they don't show you what you need to include SDK wise so a python interpreter is available! I've googles references that you need the correct SDK, but "flatpak search" doesn't return those. > You've more or less hit the nail on the head for why I've personally not been interested in Flatpaks. There's definitely some cool technology there, but clearly it's not made for humans to work with. It feels like you need too much built-in knowledge and understanding of the pieces below you that do automagic to be able to use it well. In essence, it feels a lot like how Debian packaging tooling feels to me (in the bad ways). I try to avoid talking about this much, because historically I haven't felt that my opinion would be valued there, but as a game developer of an open source game, these kinds of things have held some degree of interest for me. I considered making a Flatpak, and later taking over the Flatpak in Flathub once one became available, but I absolutely abhor the experience for developing and maintaining Flatpaks. As you noted, the experience for developing Flatpaks is pretty bad. The experience for Flathub indicates that nobody has seriously thought about how a developer experience for producing and submitting Flatpaks should work. I mean, really? Submitting GitHub PRs to a "null repo" and then manually going through crap to transfer that into an individual repo, then closing the PR? That's seriously speaking to lack of interest in making a coherent and streamlined developer experience. Now all of these problems are only unique to the GNOME implementation of Flatpak. Fedora's implementation of Flatpak works a bit differently, leveraging the Modularity technology to get things working. With the Fedora implementation, there's still a few problems: * Everything *still* has to get built over and over, which is frankly quite dumb and wasteful, especially since we *know* what version of Fedora everything is built for. Reuse would be a major accelerator of adoption. * It is somewhat unclear how the build orchestration works. I know that a modulemd.yaml is involved and some kind of container build definition, but not much else. * The Flatpak naming restriction makes things get really ugly since you need to force to fit RDNN naming convention. The submission experience for new flatpaks is essentially the same as RPMs. So while not good, it's not entirely awful like the Flathub one is. Maybe one day that will be improved for RPMs, containers, modules, and Flatpaks... You may find that Fedora Flatpaks will be a better way to get your app built. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
