Flatpak and/or snap packages

[Mikaela]

Both Flatpak.org and Snapcraft.io are attempting to be universal package managers across distributions and make it easier for the package to stay up to date than in traditional repositories.

• http://docs.flatpak.org/en/latest/
• https://docs.snapcraft.io/build-snaps/

I think the main difference is that Flatpak is more for GUI apps and Snap is somewhat tied to Ubuntu by supporting only one repository at a time (while Flatpak handles multiple).

Why I am requesting this is that when I heard of SyncPlay, I attempted to find it from flathub.org, snap and Ubuntu repositories without success and then it took me some time to find the packages I needed to run it and now it's in specific directory outside of all paclage managers and I will need to rely on SyncPlay to update itself or check for updates when I need it instead of it getting updated as I update rest of the system (or when flatpak/snap updated automatically).

[albertosottile]

I am not a Linux developer but, AFAIK, both flatpaks and snaps run their content inside a sandbox and I am not sure how this could affect Syncplay, given its interactions with media players. It could also worth a shot to provide a regular Debian package.

[daniel-123]

I have done some research into flatpak and snap. My findings were as follows:

• snap indeed is still mostly niche and limited to Ubuntu. That alone probably makes it not worth the effort.
• flatpak has sandboxing which seems to be incompatible with current model of integration with media players Syncplay uses. I'm not extensively familiar with it, but for now only working solution I see would be outright bundling the media player within flatpak. Which is a large extra support burden.

I have looked several times into creating a .deb or .rmp. If it is just about creating a package that will work it isn't actually hard, but inclusion of it into repositories of established distributions is completely different problem.

What I have been playing around with recently though is how to make it installable with pip. This is something I'll probably end up doing first.

[TingPing]

flatpak has sandboxing which seems to be incompatible with current model of integration with media players Syncplay uses. I'm not extensively familiar with it, but for now only working solution I see would be outright bundling the media player within flatpak. Which is a large extra support burden.

Hey Flatpak guy here. So I'm not too familiar with Syncplay but the solution that sounds most logical to me is having syncplay simply be an extension to other media player flatpaks. I am assuming that it installs a plugin that is loaded by MPV/VLC/etc.

It would show up in software centers like this:

[albertosottile]

@daniel-123 Yeah, I heard that getting in a repository is quite hard, but that's the first place I look for software, so we might want to pursue it somehow. What would you do to reach that goal? As much as I like pip, I do not feel Syncplay as a python module, so that's probably not the best approach. If we can't get a package approved, maybe we could just make the installation instructions for Linux a little more prominent. After all, we do not have that many dependencies.

@TingPing Thanks for stepping up. Your option seems nice, I just have a quick question: do the media player developers (or the maintainers of their flatpaks) need to actively support our add-on? In other words, is it possible for anyone to publish autonomously an add-on for any existing flatpack?

[TingPing]

I just have a quick question: do the media player developers (or the maintainers of their flatpaks) need to actively support our add-on? In other words, is it possible for anyone to publish autonomously an add-on for any existing flatpack?

It would roughly be a one time cost. Their package has to define an extension point and they have to ensure the media player loads plugins from that location. After that plugins just dump their files there basically.

[S2F0amEgS2xvdmVy]

The flatpak idea by TingPing looks really cool to me! It seems a little complicated though.

I was looking into creating an AppImage of Syncplay, because it is my understanding that you can simply use mpv and youtube-dl as usual that way.

[albertosottile]

I think we have to divide this issue into two distinct problems: the first one is the packaging of Syncplay, the other one is discoverability of these packages.

Packaging can be quickly solved by using PyInstaller, also considering that we will have to use that on Windows soon. It is certainly possible to use it on Linux, with minimal edits of the config file, if our goal is to have a single-file executable binary on that platform too.

However, things like PyInstaller or AppImage will not solve the second problem, discoverability of such binaries. My understanding is that only getting a package in a somewhat official repository will solve this problem for real and, unfortunately, this result is quite unlikely to achieve, mostly for political reasons. I am not sure about the popularity of flatpacks or snaps, but it seems to me that the outcome will probably not justify the effort needed.

In summary, I believe that, for now, we can only mitigate the first problem. Specifically, if Linux users perceive that finding dependencies is tricky, we could distribute a single-file binary for Linux too. Or. we could prepare a detailed installation instruction page for Linux, perhaps listing the names of the packages needed to run Syncplay from sources, maybe targeting some different distributions. I would like to hear the opinion of Linux users of Syncplay on this matter.

[Xcelled]

My preferred installation method would be a pip package. This could coexist with other distribution mechanisms if needed or desired. Copying from #206:

There's precedent for using pip to install "apps", eg https://github.com/nvbn/thefuck. Also setup.py provides a mechanism for registering python scripts as executables.

I'd make the argument that, since syncplay doesn't install required packages automatically, pip knowledge is still required to get syncplay running and that not leveraging setup.py's dependency mechanisms means that more pip knowledge is required. Case in point: I didn't know that PySide1.x was called python3-pyside. Sure, I could have looked it up, but that's beside the point.

With a pip package, Linux users would still be free to obtain packages any way they want, but could just do pip install syncplay to quickly get everything needed.

[albertosottile]

My preferred installation method would be a pip package. This could coexist with other distribution
mechanisms if needed or desired

@Xcelled I have a naive question about this. Is a pip package supposed to work on all the supported platforms (Windows, macOS, Linux) at the same time?

[albertosottile]

A small status update: as per my last comment in issue #207, using setuptools (hence pip) to distribute Syncplay is currently not a viable option due to the mismatch between our project structure and the one of python modules or packages.

Other options for improving the distribution on Linux are still on the table (e.g. PyInstaller or AppImage), and we are still waiting for feedback from the users about these.

[Et0h]

I am closing this as Syncplay was not designed to be Flatpak and/or Snap compatible and it seems that nobody has managed to accomplish this in the five months since this suggestion was made.

Syncplay is not an extension, it is its own software - however, it uses interface lua scripts to connect with VLC and mpv. For VLC this has to be in a VLC folder, but for mpv this can be in the Syncplay folder. I believe that @daniel-123 was correct when he commented that: "flatpak has sandboxing which seems to be incompatible with current model of integration with media players Syncplay uses".