[V3] Flatpak for linux distribution

[lionirdeadman]

Feature request

Select the type of feature you are requesting:

• Cog
• Command
• API functionality
• Core

Describe your requested feature

Distributing through flatpaks would have many benefits even though it may sound stupid at first :

• Distribution agnostic installation
• No Distribution specific issue (example the issue of the Java certificate being wrong on Ubuntu)
• Sandboxing of Java and python which would ensure the correct versions are installed and configured properly
• Updates are streamlined
• Installing multiple versions of red doesn't need any configuration with pyenv or venv

(Snapd or Appimages could also be used potentially to achieve the same results)

[mikeshardmind]

A brief look into the packaging process for these has me under the impression we could automate the builds for flatpaks with relative ease. I think it's worth at least considering as once set up, it would not require significant extra work to keep up to date.

[palmtree5]

Seems like a snap would be pretty easy as well

[Tobotimus]

Freezing for now, this distribution sounds like it has some good qualities but we're gonna focus on pip for now.

[lionirdeadman]

That's understandable. Maybe I can work on it soon. I'm very inexperienced so I wouldn't expect too much from my trials though.

[lionirdeadman]

Okay, so I'm not entirely done but most of the work has been, all that's left is cosmetics and things that are out of my control, I'll publish the script and other things needed after we make a decision since I don't know where to put the code.

So depending on if we want to publish to Flathub.org (which would be great in my opinion), we have 2 options :

1. Publish Flatpak bundles in the releases
   This allows the great compatibility that Flatpak offers but it does mean that people have to download the Flatpak from Github and doesn't offer any extra 'publicity'

2. Publish Flatpak to Flathub
   This way does mean that I'll need to make further modifications to ensure we make fully reproduceable builds and that we'll most likely need a repo under Flathub's namespace but it also makes it more accessible since it's inside Flathub's repositories which most Linux users use nowadays for cross-distribution programs.

[mikeshardmind]

Personally, I think until we have a bit more certainty, and stability, we use option 1 (bundle in releases)

This isn't ideal, as already stated, but until we have more testing with it, I wouldn't want to publish to flathub to ensure the same level of reliability we already expect from our stable releases from it, while still keeping with another set of standards (flatpak's)

This would likely mean if you have a flatpak script that is ready for use now, we could look at 3.1 or 3.2 for publishing on flathub, and have the script available on the development version until then.

We're exceptionally close to 3.0 stable now, so if this will involve changes to the bot, this will not work with 3.0, even if grabbable from GitHub. (Though, from my understanding of flatpak, it shouldn't)

[lionirdeadman]

Alright, I've outlined the current issues and improvements on my current progress in #2242.