search

streamlink / streamlink-twitch-gui

A multi platform Twitch.tv browser for Streamlink
https://streamlink.github.io/streamlink-twitch-gui/
MIT License
2.7k stars 204 forks source link

Flatpak or Snap package for Streamlink Twitch GUI #834

Closed heidiwenger closed 3 years ago

heidiwenger commented 3 years ago

Checklist

Description

Ubuntu is very popular, especially with new users. Well, i was trying to explain in a hurry on the phone how to make an AppImage executable. Only that extra effort, instead of just clicking "install" in the Software center, was too much for a commoner.

So i thought to suggest here whether a snap package for Streamlink-Twitch-GUI would be possible? Snaps are also sandboxed by default.

There is no other viable Twitch "client" for Linux currently.

Thanks.

bastimeyer commented 3 years ago

I'm not interested in snaps. Snaps are unnecessary, very controversial and the Ubuntu snap-store is proprietary software. Flatpaks are a way better alternative and are supported everywhere.

I had already tried building flatpak packages for both Streamlink and Streamlink Twitch GUI earlier this year, but I ran into issues which I don't think can be solved right now without (major) code changes in both Streamlink and Streamlink Twitch GUI.

The main issue is that flatpaks (as well as snaps) are sandboxed packages. This means that you can't simply run external software like the video player or FFmpeg for example and you need to bridge this via flatpak-spawn and forward file descriptors, pass through env vars and do a couple of other things. This then completely circumvents the sandboxing, making the whole flatpak idea very questionable, just for the sake of providing another package in another package repository.

Neither Streamlink nor Streamlink Twitch GUI however support this bridging out-of-the-box. For Streamlink alone, this may be a rather simple workaround and launching the player or ffmpeg can be done by wrapping the executables with flatpak-spawn, but for Streamlink Twitch GUI this is way more complex, because the Twitch GUI needs to resolve and validate Streamlink as well as the player, because it needs to validate the user's configuration so that it can show useful error messages.

I was approached by someone in a private conversation on Matrix last month with the same question and I explained all these issues. I don't think it's worth spending time solving this. At least I don't want to do this. If someone wants to submit pull requests, they are very welcome to do so though.

One could also build a monolithic flatpak package for example with Streamlink Twitch GUI, Streamlink and MPV packaged together so that bridging multiple applications doesn't have to be done, but that would make the whole experience extremely restrictive in terms of choice and customizability.

Point-release distros like Debian/Ubuntu with very strict packaging requirements make it very difficult for applications like Streamlink Twitch GUI to provide native packages. Streamlink Twitch GUI is built on top of NW.js, and there exists no such package in the Debian/Ubuntu repos. And if it was, it would probably not be maintained and updated. That's why the Twitch GUI releases embed a pre-built NW.js release, which gets built by the NW.js developers themselves. Building NW.js yourself is very expensive, as it's a fork of Chromium and NodeJS. It's not worth the effort to maintain all this so that native packages for Debian/Ubuntu could exist. At least I am lacking the experience in this regard (especially since I don't use Debian based distros).

I've also already tried providing custom package repositories, but this is limited by the hosters and their available monthly data traffic. I am surely not going to pay for hosting my own FOSS software.

While packages for Streamlink exist on Debian/Ubuntu, packaging it is a major pain and unnecessarily confusing for inexperienced/new users, especially on older point-releases which are always outdated.

That's why providing AppImages is the easiest choice so far, for me as the developer of both applications, for me as the maintainer of both AppImages, as well as for the users who are able to download and use these applications in a rather simple way.

Regarding making AppImages executable, this is only a matter of one chmod +x filename command or four clicks in a file browser (right click, properties, make executable, OK). I don't see a problem with that.

heidiwenger commented 3 years ago

I was approached by someone in a private conversation on Matrix last month with the same question and I explained all these issues. I don't think it's worth spending time solving this. At least I don't want to do this. If someone wants to submit pull requests, they are very welcome to do so though.

Oh ok. So i take this, that if someone creates a working snap package, you would accept it here though? Or a flatpak? I mean, as "we" find it hard to see that chmodding a file to make it executable is a problem, it really is for occasional and regular PC user. If the software does not fly with a single click install; they'll just leave it there generally speaking.

People also are used to mobile way of doing things now. Tap this tap that and GO. I find it pity that anyone has to leave oneself out because of unnecessary effort on just making a program launch. I understand (as so many in Linux community) that snaps and flatpak need alot of work still, and things are NOT currently all rosey ... But they are a great work in progress.

Thanks.

bastimeyer commented 3 years ago

I was talking about fixing the issues and implementing specific flatpak workarounds into the applications, because this is a requirement for circumventing the sandboxing.

To be honest, I am ok with "occasional and regular PC users" having to figure out how to make appimages executable. This is documented everywhere, in Streamlink's docs and in Streamlink Twitch GUI's wiki. If people don't want to read and learn, then this is not my problem. There are also tools for this which do this automatically, which is also documented.

As said, I'm not interested in snaps. And flatpaks are currently not worth the effort, so I'm going to close the thread... Not sure why you've posted this youtube link...

heidiwenger commented 3 years ago

I was talking about fixing the issues and implementing specific flatpak workarounds into the applications, because this is a requirement for circumventing the sandboxing.

To be honest, I am ok with "occasional and regular PC users" having to figure out how to make appimages executable. This is documented everywhere, in Streamlink's docs and in Streamlink Twitch GUI's wiki. If people don't want to read and learn, then this is not my problem. There are also tools for this which do this automatically, which is also documented.

As said, I'm not interested in snaps. And flatpaks are currently not worth the effort, so I'm going to close the thread... Not sure why you've posted this youtube link...

Yea i was posting a video in other place, it was an accident :D

superrnovae commented 2 years ago

Now that ffmpeg codecs are available in freedesktop's runtime, would it be possible for the application to be packaged as a flatpak?

bastimeyer commented 2 years ago

would it be possible for the application to be packaged as a flatpak?

No. I have already answered this in detail in my comment above. Read it. https://github.com/streamlink/streamlink-twitch-gui/issues/834#issuecomment-945017671

Unless someone submits pull requests for both Streamlink and Streamlink Twitch GUI which work around the sandboxing (as described above), this won't happen. I am not interested in spending any time on implementing this myself, and I am not interested in discussing this further.

There are appimages available if your distro's native package manager doesn't include (recent) packages for Streamlink and/or Streamlink Twitch GUI, so use these.

And if one wants to build an "opinionated flatpak package" for Streamlink Twitch GUI that bundles

  1. Python + dependencies
  2. Streamlink + dependencies
  3. Streamlink Twitch GUI + dependencies
  4. MPV or VLC + dependencies

so that the sandboxing doesn't need to get worked around, then they can do that themselves.