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 · 51 comments

Comments

Projects
None yet
@jmcphers
Copy link
Member

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

branchus commented Aug 21, 2018

I would vote the AppImage
Thanks

@btreut

This comment has been minimized.

Copy link

btreut commented Sep 5, 2018

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

@J-J-Chiarella

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

btreut commented Dec 20, 2018

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

@Enchufa2

This comment has been minimized.

Copy link

Enchufa2 commented Dec 20, 2018

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

@Enchufa2

This comment has been minimized.

Copy link

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?

@msberends

This comment has been minimized.

Copy link

msberends commented Dec 26, 2018

@probonopd

(about AppImage) Just download, make executable, and run.

Yeah, so that’s EXACTLY what you shouldn’t want, that’s horribly un-user friendly. I use Ubuntu for research (like probably millions of others do too) and I run RStudio on it. I just want my package manager (Software Update) to update it automatically whenever a new version is available, pretty much like all other (serious) software. Wouldn’t that be very obvious to have for RStudio?

@probonopd

This comment has been minimized.

Copy link

probonopd commented Dec 27, 2018

@msberends your use case is a rather narrow one - if that is what you want, then why not use whathever your distribution ships and call it a day. I happen to run 5 different application versions alongside each other (one being git master), and I would like the same exact application versions no matter whether I happen to be on a Debian, Fedora, or openSUSE box at that particular day. And I like the application versions to come directly from the application author, who will directly support them.

@branchus

This comment has been minimized.

Copy link

branchus commented Dec 27, 2018

I too find some flatpack package are pretty large, in this case the Rstudio is 1.2GB.

I prefer the AppImage, everything in a single package, just download and run.

@msberends

This comment has been minimized.

Copy link

msberends commented Dec 27, 2018

your use case is a rather narrow one

We don’t know, now do we 😉
All I see around me (at work) is that people just install software and want to keep it updated as easy as possible, call it the Windows or macOS way. I don’t think that’s a narrow group, especially for non-developers. So we can conclude that there are different use cases. Maybe time to investigate the popularity of these? And not through a poll here, please 😄 That’s selection bias - GitHub is for developers, which I expect most users are not.
So maybe raise something on the RStudio website, show this question in the Linux preview version, anything. Really, I think most users, even on Linux, would just be satisfied with an automated update process and not with downloading manually and installing or chmod-ing files manually afterwards.

no matter whether I happen to be on a Debian, Fedora, or openSUSE box at that particular day.

Because I think that that’s narrow 😉 You’re obviously a developer, and that’s awesome. Just don’t forget RStudio users use more packages than develop them.

@Enchufa2

This comment has been minimized.

Copy link

Enchufa2 commented Dec 27, 2018

@probonopd: "@msberends your use case is a rather narrow one", says the person who happens to "run 5 different application versions alongside each other". ¯_(ツ)_/¯

@branchus:

I too find some flatpack package are pretty large, in this case the Rstudio is 1.2GB.

I prefer the AppImage, everything in a single package, just download and run.

If the flatpak is so large, the appimage won't be magically smaller.

@probonopd

This comment has been minimized.

Copy link

probonopd commented Dec 27, 2018

@probonopd: "@msberends your use case is a rather narrow one", says the person who happens to "run 5 different application versions alongside each other". ¯_(ツ)_/¯

Yes, my use case is broader, more complex, not as narrow. (There are fewer users running such a setup, granted, but that doesn't mean that there aren't any.)

If the flatpak is so large, the appimage won't be magically smaller.

It depends. AppImage keeps all resources compressed on disk, uses basic infrastructure (such as glibc) from the system, and well-built AppImages only ship the subset of resources actually needed by an application (e.g., just a small subset of Qt).

So it may well be smaller.

@Enchufa2

This comment has been minimized.

Copy link

Enchufa2 commented Dec 27, 2018

@probonopd: "@msberends your use case is a rather narrow one", says the person who happens to "run 5 different application versions alongside each other". ¯_(ツ)_/¯

Yes, my use case is broader, more complex, not as narrow. (There are fewer users running such a setup, granted, but that doesn't mean that there aren't any.)

More complex, for sure; I wouldn't call it broader though, since it's very specific. But anyway, call it whatever you want. The point about a use case is how common it is.

If the flatpak is so large, the appimage won't be magically smaller.

It depends. AppImage keeps all resources compressed on disk, uses basic infrastructure (such as glibc) from the system, and well-built AppImages only ship the subset of resources actually needed by an application (e.g., just a small subset of Qt).

So it may well be smaller.

And one of the main features of Flatpak is that you can reuse runtimes (e.g., Qt) across apps, so that you don't need to package any Qt library at all. This is why I was surprised about the file size.

@btreut

This comment has been minimized.

Copy link

btreut commented Jan 2, 2019

The only thing is that 1.2 GB is quite a lot. Why is it so big compared to other bundles?

@Enchufa2: good point, but I don't know why it is that large. Alexander Wilms' first bundle was around 750MB, and thus quite smaller. I do not clearly understand, what can be seen in my private repository (I dubbed it my-flathub) and what the bundling process packs up in the bundle, when I issue the command flatpak build-bundle my-flathub rstudio.flatpak com.rstudio.RStudio, but as far as I understood the build process, an almost complete version of texlive is included in the bundle together with R, and lots of other stuff (maybe compiler and/or other development utils, since the install.packages("tidyverse") apparently also compiles some stuff). This might explain a bit of the size. I do not have a deep understanding of flatpak, I followed only the recipes for creating a flatpak and with some guessing I was able to fill my private repository and build a single file bundle from that, see my build notes in the Endless community forum.

PS: On my Q4OS build system, which is Debian 9 based, I installed R-Studio via the deb package provided at rstudio.com. It installed a huge amount of dependencies and failed miserably when I tried the to install the tidyverse package via install.packages("tidyverse"), which is necessary for using r4ds as a tutorial. This error did not occur when I used the flatpak for R-Studio, so I was positively surprised and I am even convinced that flatpak is a good way for distributing complex applicattions. I think I mentioned already that I am mainly interested in using R and R-Studio, but as flatpaks, R, and R-Studio are concerned, I am a complete newbie.

@Enchufa2

This comment has been minimized.

Copy link

Enchufa2 commented Jan 2, 2019

@btreut RStudio can use any installation of R. You should be able to install any R version, even multiple versions, and tell RStudio which one you'd like to run at any given time. So IMO the flatpak shouldn't bundle neither R or texlive, but use the system's ones.

@btreut

This comment has been minimized.

Copy link

btreut commented Jan 2, 2019

IMO the flatpak shouldn't bundle neither R or texlive, but use the system's ones.

hmm, my main interest was getting R with some graphical frontend on EndlessOS. There was/is no R for EndlessOS, which (despite being Debian based) uses flatpak as only installable package format. In principle I can follow your arguments, but such a flatpak would be quite useless for EndlessOS and then for me also.

@Enchufa2

This comment has been minimized.

Copy link

Enchufa2 commented Jan 10, 2019

IMO the flatpak shouldn't bundle neither R or texlive, but use the system's ones.

hmm, my main interest was getting R with some graphical frontend on EndlessOS. There was/is no R for EndlessOS, which (despite being Debian based) uses flatpak as only installable package format. In principle I can follow your arguments, but such a flatpak would be quite useless for EndlessOS and then for me also.

Then, given that there are other apps that use R (e.g., jamovi), the best way to go would be to bundle R as a runtime extension, as @TingPing suggests here. As for texlive, it already is an extension.

@TingPing

This comment has been minimized.

Copy link

TingPing commented Jan 10, 2019

Randomly jumping in since I was pingged but yes Flatpaks must contain everything required to execute a program, the entire point is to be portable and not rely on any host state beyond a few services. This is a good thing because it means you can ensure that anybody with Flatpak has all the tools needed and you never have to guess about host state being there, being ABI compatible, a new enough version, etc. You can make them extensions for optional bits (possibly maintained by somebody else) but still they are flatpak'd.

@btreut

This comment has been minimized.

Copy link

btreut commented Jan 13, 2019

@Enchufa2

there are other apps that use R (e.g., jamovi)

thanks for that pointer. I did not know jamovi, it looks interesting

@znmeb

This comment has been minimized.

Copy link

znmeb commented Jan 22, 2019

What's the latest on this?

@jmcphers

This comment has been minimized.

Copy link
Member Author

jmcphers commented Jan 22, 2019

What's the latest on this?

We're currently working on closing down RStudio 1.2, and will be re-evaluating this when work begins in earnest on RStudio 1.3.

@keberwein

This comment has been minimized.

Copy link

keberwein commented Jan 26, 2019

This issue has been a huge blocker in my personal development.
Flatpak, or a private repository is another option.
I understand this is proprietary software, but...

@msberends

This comment has been minimized.

Copy link

msberends commented Jan 26, 2019

I understand this is proprietary software

It’s not!

@keberwein

This comment has been minimized.

Copy link

keberwein commented Jan 26, 2019

It’s not!

My mistake, I've never seen it in any Linux repos (not even Arch), so I assumed there was a proprietary license.
Could it be as easy as someone packaging it and submitting it to the Yum/DNF and APT repos? I mean that would make the Flatpak issue moot.

@btreut

This comment has been minimized.

Copy link

btreut commented Jan 28, 2019

What's the latest on this?

hmm, I was able to use the manifest to create a RStudio flatpak and it works. As Enchufa2 mentioned, it is huge so there is quite some potential for optimizing it.

@btreut

This comment has been minimized.

Copy link

btreut commented Jan 28, 2019

What's the latest on this?

We're currently working on closing down RStudio 1.2, and will be re-evaluating this when work begins in earnest on RStudio 1.3.

good news, thanks in advance.

When I look for the version via Help->About Rstudio it tells me that I am using RStudio Version 99.9.9, so I guess the manifest fetched some current development version from github for creating the flatpak @Alexander-Wilms: might that be possible

@Alexander-Wilms

This comment has been minimized.

Copy link

Alexander-Wilms commented Jan 28, 2019

Yes, the Flatpak manifest currently builds the master branch of RStudio.

@btreut

This comment has been minimized.

Copy link

btreut commented Jan 29, 2019

Yes, the Flatpak manifest currently builds the master branch of RStudio.

how could I change that to e.g. v1.1.463, i.e. the current stable version.

@Alexander-Wilms

This comment has been minimized.

Copy link

Alexander-Wilms commented Jan 29, 2019

Change

  - type: git
    url: https://github.com/rstudio/rstudio

to

  - type: git
    url: https://github.com/rstudio/rstudio
    branch: v1.1.463
@btreut

This comment has been minimized.

Copy link

btreut commented Feb 13, 2019

We're currently working on closing down RStudio 1.2, and will be re-evaluating this when work begins in earnest on RStudio 1.3.

I am slightly puzzled and just curious: are even subnumbers development versions and odd subnumbers final (and/or corrected/patched final versions)?

I find at RStudio releases a huge number (2958) of releases and the majority are with odd minor version numbers and only rarely with even. And on the download page I see only the latest with odd minor version. Neither friend google nor a quick search in the community forum yielded some insight.

@gtritchie

This comment has been minimized.

Copy link
Contributor

gtritchie commented Feb 13, 2019

The download page provides the most recent official release which is 1.1.463. "Official" meaning we have completed planned feature development on it, and it has been through significant release testing and sign-off.

We have been working on 1.2 for some time and it is still under active feature development. We are nearing the point where it will become the official release.

The minor build numbers are just an increasing number based on builds (triggered by checkins). Nothing special about odd or even.

There is also a preview release download page; these are builds of 1.2 that we have done additional validation on and consider reasonably stable for testing/evaluation (but not production) use.

https://www.rstudio.com/products/rstudio/download/preview/

@kevinushey

This comment has been minimized.

Copy link
Contributor

kevinushey commented Feb 13, 2019

I find at RStudio releases a huge number (2958) of releases and the majority are with odd minor version numbers and only rarely with even. And on the download page I see only the latest with odd minor version. Neither friend google nor a quick search in the community forum yielded some insight.

These are not 'real' releases. In the past, we tagged each build in Git primarily so we could easily find which particular version of RStudio was built from a particular commit (and it was easy to jump back in time to the sources as they were when a particular version of RStudio was built). IIUC GitHub implements this 'tags are releases' idea a long time after we had adopted this scheme and so all these prior tags get gobbled up as 'releases' in the GitHub UI.

@btreut

This comment has been minimized.

Copy link

btreut commented Feb 15, 2019

Tanks a lot for the clarifications.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment