Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bundle RStudio Desktop for Linux as a Flatpak, Snap, or AppImage #3079

Open
jmcphers opened this issue Jun 26, 2018 · 108 comments
Open

Bundle RStudio Desktop for Linux as a Flatpak, Snap, or AppImage #3079

jmcphers opened this issue Jun 26, 2018 · 108 comments

Comments

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Jun 26, 2018

As of this writing, we are currently building no fewer than five different versions of RStudio Desktop for Linux:

  1. for RedHat/CentOS based systems;
  2. for Ubuntu based systems;
  3. for OpenSuSE based systems with an old libssl;
  4. for OpenSuSE based systems with a new libssl; and
  5. for Debian 9+ based systems.

Despite this somewhat cumbersome matrix we still don't support many platforms and distributions.

This is a general issue with Linux applications, at least on the desktop; because of differing installation systems, packaging requirements, and system libraries, packages conforming to each system's idiosyncrasies are necessary.

Several attempts have been made to solve the problem by introducing an installation platform which encourages the bundling of dependencies (rather than relying on system versions), making application deployment on Linux more like it is on Mac/Windows. In true Linux fashion, there are many competing efforts:

Flatpak - https://flatpak.org/

Snapcraft - https://snapcraft.io/

AppImage - https://appimage.org/

We should evaluate these technologies in the next release cycle or so and see if any would be a good choice for RStudio Desktop (and in particular whether it'd allow us to simplify things or simply introduce a sixth variation!).

@btreut
Copy link

@btreut btreut commented Jul 28, 2018

what about a kind of voting/poll for getting some impression about which version would currently be most attractive?

Alexander Wilms aready provided a manifest for creating a flatpak of RStudio.

I would vote for flatpak. Who else?

@probonopd
Copy link

@probonopd probonopd commented Aug 2, 2018

I would vote for #AppImage, because a properly built one will run on both Ubuntu and Fedora (and most other popular mainstream Linux distributions) out-of-the-box.

@KIC
Copy link

@KIC KIC commented Aug 3, 2018

I vote for snap as this seems to be the winning standard at least for developers. I have vscode, node and intellij via snap as well as a whole developers kubernetis single node cluster installed via snap.

@branchus
Copy link

@branchus branchus commented Aug 21, 2018

I would vote the AppImage
Thanks

@btreut
Copy link

@btreut btreut commented Sep 5, 2018

today I found: another instruction for creating/installing rstudio flatpak. Does anybody have experiences with it?

@J-J-Chiarella
Copy link

@J-J-Chiarella J-J-Chiarella commented Sep 16, 2018

if the straw poll is still on, I vote flatpak. It is the most "usable" to the largest group and offers the best system of sandboxing. AppImage has its pluses and is the most like a windows self-contained .exe, but there are reasons it hasn't caught on or undergone the intense development of flatpak or snap in the past couple of years.

@probonopd
Copy link

@probonopd probonopd commented Sep 18, 2018

@J-J-Chiarella AppImage is seeing great momentum with more and more upstream applications using the format and is being developed actively in the community (over 3,600 stars on GitHub). Unlike the other two solutions, it is not pushed by one of the large Linux distribution companies, and hence does not have the same level of PR though.

The point, however, is: Flatpak/snap (deep system integration) one the one hand and AppImage (portable one-file apps) on the other hand serve different purposes. So why not have both.

@Enchufa2
Copy link
Contributor

@Enchufa2 Enchufa2 commented Oct 31, 2018

Snap was designed with application stores and communication interfaces between apps in mind, while Flatpak was developed with graphical applications and runtimes in mind. IMHO, snap is best suited for servers and in general for headless devices, while Flatpak is best suited for desktops.

E.g., Fedora just released Fedora Silverblue, a variant of Fedora Workstation which is an immutable OSTree-based image + Flatpak for desktop apps (+ Fedora Toolbox to enable containerised mutable development environments).

@JBuursma
Copy link

@JBuursma JBuursma commented Nov 26, 2018

I thank the RStudio team for considering this issue. I know Linux users are probably a small percentage of your user base & the competing standards makes supporting them hard (the fact that the first three comments gave three different preferences is so classic), so I appreciate your efforts.

Question: what problem(s) are you trying to solve by supporting another packaging format? The first sentence of this thread mentions the desire to support as many distros as possible. Which distros are not currently supported that you want to support? I don't see Arch there, but I believe RStudio is in the AUR. So... Slackware? Puppy Linux?

In my mind, the biggest pain point of the current RStudio packaging approach is not which distros are supported (I mostly live in deb land, so I'm feeling sufficiently supported), but greater user-friendliness. I would love a packaging format that was able to update automatically without having to manually redownload a binary from the RStudio download page every so often. I know that both snap & flatplak have this feature (although for some distros you might have to manually run snap refresh or flatpak update). Does AppImage?

I also think AppImage is less broadly user-friendly in that it doesn't automatically install to the system menu like snap & flatpak do. Downloading, chmod'ing, and running from the terminal means it might be great for power users & certain specific use cases, but be otherwise less friendly. (Different purposes, as probonopd says.)

Again, thanks for your consideration and your great software.

@jmcphers
Copy link
Member Author

@jmcphers jmcphers commented Nov 26, 2018

what problem(s) are you trying to solve by supporting another packaging format?

  1. Reduction of the number of platforms we have to build and test for. A relatively self-contained image would reduce development complexity and allow us to better focus our testing efforts.
  2. Insulation from system dependencies. External libraries change in incompatible ways often on Linux; a recent example is libgstreamer-0.1, which RStudio depends on, but which Debian removed in Debian 9. When Debian removed it, we had to scramble to make custom Qt 5 builds compatible with Debian 9, and produce a new, separate RStudio release for Debian 9 users. Most of these package formats bundle dependencies to an extent, which helps slow down the treadmill.
  3. Improved installation (and possibly upgrade) experience for end users: just download and run it, like you can on Mac and Windows. If you're on a non-mainstream distribution, or an usually old or new one, or have trouble with dependencies, installation can be a challenge. Most of these alternative packaging formats help provide an escape hatch for this long tail.
@wilx
Copy link

@wilx wilx commented Nov 26, 2018

Gstreamer 0.1 has been dead for years now. Why are you depending on technology that has become obsolete in 2012?

@jmcphers
Copy link
Member Author

@jmcphers jmcphers commented Nov 26, 2018

We aren't any more, but old versions of RStudio needed it since they were built on (even older) versions of Qt, which in turn included (even older) versions of QtWebKit that required it. RStudio 1.2 uses QtWebEngine instead, which has no libgstreamer dependency.

@JBuursma
Copy link

@JBuursma JBuursma commented Nov 28, 2018

It's always a bit "brave" to drop support for a format you've already been supporting, :-) and I'm not sure whether any of these three new choices would extend well to a "non-mainstream distribution, or an usually old ... one". But, I would think that supporting Flatpaks or Snaps going forward would at least reduce the number of new strange configurations you might have to add. For example, if a situation like that with libgstreamer-0.1 ever happened again, you could decide not to create another deb format and direct people to a Snap package (for example) instead. It's hard for me to imagine most users not preferring that to another deb or rpm to manually download.

@probonopd
Copy link

@probonopd probonopd commented Nov 28, 2018

I would love a packaging format that was able to update automatically without having to manually redownload a binary from the RStudio download page every so often.

Check https://github.com/AppImage/AppImageUpdate/

I also think AppImage is less broadly user-friendly in that it doesn't automatically install to the system menu like snap & flatpak do.

Check https://github.com/AppImage/appimaged or https://github.com/TheAssassin/AppImageLauncher/

@btreut
Copy link

@btreut btreut commented Dec 7, 2018

I have tried the manifest of Alexander Wilms for creating a flatpak for RStudio and have tried to write up, what I did in the Endless community forum. RStudio works in Q4OS (which is a Trinity based Debian clone). Now, after having found the infos about Single-file bundles, I am trying to create a rstudio flatpak bundle. If I succeed and it works on Endless, I will provide it for some limited time for testing.

@btreut
Copy link

@btreut btreut commented Dec 11, 2018

I was able to install the rstudio bundle in endless. It starts up without problems, but since I am still a R newbie: is there any test suite, which I could use to check that everything (or better most things) are running correctly?

In any case: everybody who is interested is invited to fetch that bundle from here: ftp://ftp.lrz.de/transfer/flathub/rstudio.flatpak. It will stay there for some weeks, but it will be deleted by our central site admins without notice if they need the space. Beware: if you do a directory listing of the parent, i.e. ftp://ftp.lrz.de/transfer/ you will not see anything.

@probonopd
Copy link

@probonopd probonopd commented Dec 11, 2018

Now, after having found the infos about Single-file bundles, I am trying to create a rstudio flatpak bundle

Have you looked into the AppImage format as well? These are single-file bundles that can actually be executed without the need for installation or special management tools. Just download, make executable, and run. Optionally users can, if they so desire, extract the contents from the AppImage.

@btreut
Copy link

@btreut btreut commented Dec 12, 2018

No, I did not look at appimage. I need flatpak, since afaik it is the only package format for EndlessOS.

@probonopd
Copy link

@probonopd probonopd commented Dec 12, 2018

I have never tried Endless OS (because my Acer computer that was advertised to come with it turned out to come with a broken Linpus Lite Linux instead) but possibly AppImage might work there, too.

@btreut
Copy link

@btreut btreut commented Dec 12, 2018

hmm, for me it was the other way: I expected linpus and got endless. May impression is: EndlessOS is fascinating system despite it supports only flatpak out of the box. Maybe I could pack AppImage on top of flatpak, but honestly I think this would be a kind of an overkill, since both intend to solve similar problems ...

The people of flathub say that they would prefer a pull request from upstream. I think this is quite reasonable. But since there was no progress since months, I tested Alexander Wilms yaml manifest on my own with quite some success, see my notes in the Endless Community Forum. But I would prefer to run some kind of test suite before saying: RStudio flatpak runs flawlessly.

@btreut
Copy link

@btreut btreut commented Dec 17, 2018

RStudio flatpak runs at least on two quite different platforms, see some test results at R Studio Community using R4DS as tutorial.

@btreut
Copy link

@btreut btreut commented Dec 20, 2018

You can download the rstudio.flatpak and join testing, see my previous post for the ftp-address.

@Enchufa2
Copy link
Contributor

@Enchufa2 Enchufa2 commented Dec 20, 2018

Thanks, I'll try to find some time to test this and provide some feedback the next week.

@Enchufa2
Copy link
Contributor

@Enchufa2 Enchufa2 commented Dec 26, 2018

I've tried it and it seems to work ok (Fedora 29, R 3.5.1, KDE Plasma 5.14.4, Qt 5.11.1). The only thing is that 1.2 GB is quite a lot. Why is it so big compared to other bundles?

@branchus
Copy link

@branchus branchus commented Mar 3, 2020

FYI, I've re-packaged both rstudio-desktop and rstudio-server for Fedora, and they have been accepted in the official repos. It will be immediately available for rawhide once it's built, but it will still take a few days until the package is sent to updates-testing and then reaches the stable status for F31.

Thank you. I'm a fedora user and happy to see the package is coming.

@pstils
Copy link

@pstils pstils commented May 5, 2020

Having had an issues with the current stable rstudio release on a hidpi laptop running ubuntu 20.04 - some dependency issue to do with the Qt version, IDK - I would vote for flatpack, snap, or appimage. Not a very helpful post, I know, but although there's pros and cons to each app package, at the end of the day having any one of them available would be fantastic.

@btreut
Copy link

@btreut btreut commented Nov 27, 2020

apparently https://github.com/HarryMichal/rstudio-flatpak is ready to be tested since April, 2020...

@kevinushey wrote on on Nov 4, 2019:

We're not abandoning the effort, but we won't have time to accomplish this for the v1.3 release and so will defer this to a future release.

V1.3 is out since May, 2020 ... any pogress with flatpak, snap, or appimage?

@eoli3n
Copy link

@eoli3n eoli3n commented Nov 30, 2020

is that 2020 ?

@btreut
Copy link

@btreut btreut commented Nov 30, 2020

is that 2020 ?

what?

@eoli3n: I cited in my posting with years, so I don't understand your question

@eoli3n
Copy link

@eoli3n eoli3n commented Nov 30, 2020

That's not a question for you. I meant that, in 2020, the need of dpkg -i whatever.deb and update manually is crazy.
Then 2 years and half to choose a package manager, and still nothing.

@btreut
Copy link

@btreut btreut commented Nov 30, 2020

yes, @eoli3n is correct, the discussion about Flatpak, Snap, or AppImage started in June, 2018 and there isn't anything on horizon ...

@casperl
Copy link

@casperl casperl commented Dec 5, 2020

Most of these alternative packaging formats help provide an escape hatch for this long tail.

I will add that Snap and Flatpak are fast, safe and transparent ways for users to be running the latest release of software. AFAIK the AppImage format does not have an auto-update feature, but in one or two cases I specifically use AppImages in order to run an older release of programs that has a lower system overhead.

Specifically Snap (but possibly also FlatPak) images have the benefit that should something be broken and be fixed, the update is automatically loaded the next time that a Snap app is started. This is a major benefit for developers where calls relating to bugs in old versions are significantly reduced.

@probonopd
Copy link

@probonopd probonopd commented Dec 5, 2020

I will add that AppImage is an even faster and more transparent way for users to be running the latest release of software.

AppImage format does not have an auto-update feature

AppImages can update themselves if the author of the AppImage chooses to put that functionality into the AppImage. For example FreeCAD starting from 0.19.21514 can update itself.

The philosophy of AppImage is that nothing updates itself automatically, only if the user specifically asks for an update. And even then, the old version is kept around until the user explicity deletes the old version.

So that the user is always in full control and can try out the latest bleeding edge versions without any risk.

It is a design princinple of AppImage that applications coming in this format can be managed entirely separately from the rest of the system. You can update an AppImage at any time without impacting anything else on your system.

And the application author has complete freedom over which versions of which dependencies to put inside the AppImage, allowing for testable, and hence supportable, combinations of libraries.

It is no coincidence that applications with complex dependencies such as Krita and Kdenlive often work much better when shipped as AppImages than when shipped in other formats, because the original application application authors are able to test the exact combination of dependencies rather than random versions choosen by distribution vendors.

@eoli3n
Copy link

@eoli3n eoli3n commented Dec 5, 2020

One hand we have Rstudio spending 2 years to choose a single distribution format, the other hand we have some software which provide a way to use it on any OS. for ex: https://github.com/sharkdp/bat#installation

@znmeb
Copy link

@znmeb znmeb commented Dec 5, 2020

Meanwhile I'm happily running RStudio Server in Docker containers via Rocker everywhere 👍

@btreut
Copy link

@btreut btreut commented Dec 7, 2020

happily running RStudio Server in Docker containers via Rocker

I tried Rocker containers, but sorrily the Rocker container(s) do not work correctly with podman, see issue in the rocker universe or discussion in the endless community

@Enchufa2
Copy link
Contributor

@Enchufa2 Enchufa2 commented Dec 7, 2020

happily running RStudio Server in Docker containers via Rocker

I tried Rocker containers, but sorrily the Rocker container(s) do not work correctly with podman, see issue in the rocker universe or discussion in the endless community

What is the problem with podman? I just run

podman run -dt -p 8787:8787 -e PASSWORD=test rocker/rstudio

in Fedora 33 and got RStudio up and running.

@btreut
Copy link

@btreut btreut commented Dec 7, 2020

I just run

podman run -dt -p 8787:8787 -e PASSWORD=test rocker/rstudio

in Fedora 33 and got RStudio up and running.

interesting. I tried it in August under EndlessOS and it did not run, but I did not try it recently, so I will retry it as soon as possible.

@btreut
Copy link

@btreut btreut commented Dec 7, 2020

I was not able to get RStudio up & running with podman run -dt -p 8787:8787 -e PASSWORD=test rocker/rstudio, but I was able to follow again @egrath's instructions given here to get RStudio (server) up & running, then I was able to log in successfully via http://localhost:8787

@Enchufa2
Copy link
Contributor

@Enchufa2 Enchufa2 commented Dec 7, 2020

I was not able to get RStudio up & running with podman run -dt -p 8787:8787 -e PASSWORD=test rocker/rstudio, but I was able to follow again @egrath's instructions given here to get RStudio (server) up & running, then I was able to log in successfully via http://localhost:8787

Maybe an old version of podman? Here:

$ podman -v
podman version 2.1.1
@btreut
Copy link

@btreut btreut commented Dec 7, 2020

Maybe an old version of podman? Here:

maybe this is the reason, I get

$ podman -v
podman version 1.5.1

Last released version appears to be 1.8.3, so Fedora seems to be ahead of its time and EndlessOS lags behind.
But as far as I know, I cannot influence the installed version under EndlessOS

@Enchufa2
Copy link
Contributor

@Enchufa2 Enchufa2 commented Dec 8, 2020

You pointed to flatpak. The last version of podman is 2.2.0. The version supported by Endless is from more than a year ago.

@btreut
Copy link

@btreut btreut commented Dec 16, 2020

You pointed to flatpak. The last version of podman is 2.2.0.

@Enchufa2 you are correct, I mixed up the versions of flatpak and podman, sorry.

@btreut
Copy link

@btreut btreut commented Dec 29, 2020

https://github.com/area-of-dev/RStudio.AppImage

thanks, but how can I use it?

@nowshed-imran
Copy link

@nowshed-imran nowshed-imran commented Mar 13, 2021

+1 for Flatpak package. I was quite surprised after not finding it on Flathub.

@btreut
Copy link

@btreut btreut commented Apr 19, 2021

@jmcphers any news on a rstudio flatpak?

as far as I can see, most of the ugly work has already been done by Harry Michal and/or Alexander Wilms ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet