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".

[jvschiavo]

I'm using syncplay with the AppImage format simply because there is no .deb on official repositories yet, but I'd love to have it on Debian/Ubuntu/Mint repos so I can get updates with my system and possibly on Flatpak too (if someone manage to make that possible)! :)

[soredake]

To be able to work fully in flatpak, flatpak first need to have ability to launch another flatpak's from inside flatpak flatpak/flatpak#2723.

[teohhanhui]

From what I understand, syncplay can connect to a running instance of the video player, no?

[soredake]

From what I understand, syncplay can connect to a running instance of the video player, no?

Syncplay is launches player, not connecting to already running, in order to fully work in flatpak syncplay needs to:

1. Have write permissions in a dir that mpv can read for lua script, that's already possible as mpv has write permissions on /tmp.
2. Have write permissions in a dir that mpv can read for ipc server, as i said above, mpv flatpak have access for /tmp so it's possible.
3. Have a way to detect another flatpak installed (can be done with flatpak-spawn rn), there's no portal for this IIRC, i will fill bug report about this to flatpak repo later.
4. Most importantly, syncplay needs a proper way to launch mpv flatpak (portal?), that's not yet possible, but can be workaround'ed with very hacky solution /usr/bin/flatpak-spawn --host flatpak run mpv --command=mpv --args, that's not a proper way, and i doubt software that do this by default can be accepted to flathub.

[teohhanhui]

Does syncplay really need to launch the player though?

Syncplay uses JSON IPC to connect to mpv: https://mpv.io/manual/stable/#json-ipc

So at least theoretically speaking it should be possible for the user to launch the player themselves, and have syncplay merely connect to it. In fact, that'd be preferable to some users like myself.

[soredake]

Does syncplay really need to launch the player though?

It does not, but then you need to manually load syncplay's .lua script in mpv, configure ipc-server path in mpv.conf, and then add option to manually enter ipc-server path in syncplay so it will know where to send commands. Most users will prefer to let syncplay launch a player, because they don't need to do all of this.

[daniel-123]

@teohhanhui:

Does syncplay really need to launch the player though?

Like @soredake mentioned - technically it's not an absolute requirement, but the usability implications prevent this from becoming a supportable release method.

[soredake]

Related: flatpak/xdg-desktop-portal#283

[soredake]

As for snap (if anyone manages to build it) there is "classic" confinement without sandboxing so syncplay will work without a problem https://snapcraft.io/docs/snap-confinement

[linux4ever07]

In the case of Flatpaks (of VLC or MPV), you can trick Syncplay into using the Flatpak with a simple shell script launcher, and name it 'vlc' or 'mpv' (not '.sh'). This makes Syncplay think it's a regular VLC or MPV binary. Just put the launcher in ~/bin, or wherever, and use that path in the Syncplay config window, when launching Syncplay.

The script code:

#!/bin/bash
flatpak run io.mpv.Mpv "$@"