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

[jmcphers]

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]

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]

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]

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]

I would vote the AppImage
Thanks

[btreut]

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

[J-J-Chiarella]

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]

@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]

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]

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]

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]

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

[jmcphers]

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]

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]

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]

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]

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]

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]

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

[probonopd]

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]

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]

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

[btreut]

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

[Enchufa2]

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

[Enchufa2]

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?

[btreut]

run it with flatpak run com.rstudio.RStudio

congratulations, it starts up nicely ...

[kevinsmia1939]

Let me know if everything work or not before I submit them to flathub.

[wilx]

I get this in R console. I am not sure if it is related to Rstudio or not:

During startup - Warning messages:
1: Setting LC_TIME failed, using "C" 
2: Setting LC_MONETARY failed, using "C" 
3: Setting LC_PAPER failed, using "C" 
4: Setting LC_MEASUREMENT failed, using "C" 

It also spams this for every invocation when trying to install packages.

I tried to open one of my projects, it asked to install missing packages and then it fails for each package like this:

* installing *source* package ‘fansi’ ...
** package ‘fansi’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
gcc -I"/app//app/lib/R/include" -DNDEBUG   -I/usr/local/include   -fpic  -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -O2 -g  -c assumptions.c -o assumptions.o
/bin/sh: line 1: gcc: command not found
make: *** [/app//app/lib/R/etc/Makeconf:168: assumptions.o] Error 127
ERROR: compilation failed for package ‘fansi’
* removing ‘/home/wilx/R/x86_64-pc-linux-gnu-library/4.1/fansi’

I do have GCC installed. Is this an effect of some kind of sandboxing?

[znmeb]

Does the Flatpak package carry an R executable or does it use the distro's R executable? R is trying to determine the locale setting which doesn't seem to be what it wants.

[kevinsmia1939]

I get this in R console. I am not sure if it is related to Rstudio or not:

During startup - Warning messages:
1: Setting LC_TIME failed, using "C" 
2: Setting LC_MONETARY failed, using "C" 
3: Setting LC_PAPER failed, using "C" 
4: Setting LC_MEASUREMENT failed, using "C" 

It also spams this for every invocation when trying to install packages.

I tried to open one of my projects, it asked to install missing packages and then it fails for each package like this:

* installing *source* package ‘fansi’ ...
** package ‘fansi’ successfully unpacked and MD5 sums checked
** using staged installation
** libs
gcc -I"/app//app/lib/R/include" -DNDEBUG   -I/usr/local/include   -fpic  -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection  -O2 -g  -c assumptions.c -o assumptions.o
/bin/sh: line 1: gcc: command not found
make: *** [/app//app/lib/R/etc/Makeconf:168: assumptions.o] Error 127
ERROR: compilation failed for package ‘fansi’
* removing ‘/home/wilx/R/x86_64-pc-linux-gnu-library/4.1/fansi’

I do have GCC installed. Is this an effect of some kind of sandboxing?

Hi, the rstudio flatpak simply does not have gcc installed. The previous runtime does not come gcc. Now a change the run tome to kde sdk so it should be there now.
Try the new build, let me know if it work.
flatpak remove rstudio
flatpak install --user https://dl.flathub.org/build-repo/63248/com.rstudio.RStudio.flatpakref

[kevinsmia1939]

Does the Flatpak package carry an R executable or does it use the distro's R executable? R is trying to determine the locale setting which doesn't seem to be what it wants.

It come with its own R executable. Try the new build, let me know if the problem still happen.

[wilx]

Regarding the environment variables message, my setting is atypical:

> s[grep("^L(C|ANG)", names(s))]
LANG                                            en_US.UTF-8
LANGUAGE                                        en_US:en
LC_ADDRESS                                      cs_CZ.UTF-8
LC_IDENTIFICATION                               cs_CZ.UTF-8
LC_MEASUREMENT                                  cs_CZ.UTF-8
LC_MONETARY                                     cs_CZ.UTF-8
LC_NAME                                         cs_CZ.UTF-8
LC_NUMERIC                                      cs_CZ.UTF-8
LC_PAPER                                        cs_CZ.UTF-8
LC_TELEPHONE                                    cs_CZ.UTF-8
LC_TIME                                         cs_CZ.UTF-8

Is it possible to give it access to machine locale or make locale data files a dependency for this?

[wilx]

So, I was able to run the installation of many packages. However, some packages require external libraries. I don't think it is practical to include everything inside the Flatpak. Would it be possible to, instead, create a minimal Rstudio which could use outside-flatpak R and other things?

[kevinsmia1939]

So, I was able to run the installation of many packages. However, some packages require external libraries. I don't think it is practical to include everything inside the Flatpak. Would it be possible to, instead, create a minimal Rstudio which could use outside-flatpak R and other things?

I could give permission to external dirs and files.
Right now I give it --filesystem=home which give permission to all files under user home dir (/home). But I can also give permission to system files.

You can try giving access to all system files (/) with
flatpak run --filesystem=host com.rstudio.RStudio

I do not see the log

1: Setting LC_TIME failed, using "C" 
2: Setting LC_MONETARY failed, using "C" 
3: Setting LC_PAPER failed, using "C" 
4: Setting LC_MEASUREMENT failed, using "C" 

How can I replicate this?

[wilx]

How can I replicate this?

I think you might need to have hybrid locale. Mine is part cs_CZ and part en_US.

[kevinsmia1939]

@wilx
does doing the --filesystem=host allow rstudio to see external libs? Can you show me how to replicate this?

[wilx]

@wilx does doing the --filesystem=host allow rstudio to see external libs? Can you show me how to replicate this?

No, it did not help. I was trying to install tcltk2 package.

[kevinsmia1939]

@wilx
After some conversation with other flatpak expert, making rstudio find external libs would defeat the purpose of flatpak.
So the option is probably, bundle the dependencies, or to not flatpak rstudio. Or if there is a prebuild plugins.

[znmeb]

@kevinsmia1939 What are you using for a build system? My guess is that Fedora would be the best for building flatpaks and Ubuntu LTS would be best for building snaps.

[kevinsmia1939]

@kevinsmia1939 What are you using for a build system? My guess is that Fedora would be the best for building flatpaks and Ubuntu LTS would be best for building snaps.

The link I gave above is from the Flathub build bot. It was not build locally.
I am using openSUSE, but there should not be any significant difference.

[znmeb]

@kevinsmia1939 RStudio has a build process for openSUSE - see https://github.com/rstudio/rstudio/blob/main/docker/jenkins/Dockerfile.opensuse15-x86_64 for the dependencies

[kevinsmia1939]

@kevinsmia1939 RStudio has a build process for openSUSE - see https://github.com/rstudio/rstudio/blob/main/docker/jenkins/Dockerfile.opensuse15-x86_64 for the dependencies

Yes, but the issue here is that Flatpak won't be able to see system installed dependencies to compile that addon (tcltk2). On regular package manager on Linux, I can just install tcl to compile tcltk2 on non-flatpak Rstudio. But Flatpak does not work like that, the flatpaked app does not interact with system installed package. So I will think what to do, either just maintain the regular Rstudio package on the distro repository or try to make RStudio flatpak work somehow.

[ilikegitlab]

@kevinsmia1939:
I do not think there is a unified opinion on what your contact said regarding flatpaks. But it is true that replying on external things becomes more and more difficult. As a result flatpaks (and IMHO also snaps, which I've other problems with) are simply not useful for rstudio. An IDE for R will always want to compile packages that rely on many external system libraries and I don't see the point in creating 4 GB rstudio flatpaks in an effort to cover all.

In the first post, it seems the only reason is making a nice binary available for everyone. In that case, flatpak and snap is simply not the right tool. (I'm on gentoo currently. Rstudio is way out of date. Having a bundle like this would solve that situation. Appimage seems to be a better fit.)

[ludvigng]

@kevinsmia1939 RStudio has a build process for openSUSE - see https://github.com/rstudio/rstudio/blob/main/docker/jenkins/Dockerfile.opensuse15-x86_64 for the dependencies

Yes, but the issue here is that Flatpak won't be able to see system installed dependencies to compile that addon (tcltk2). On regular package manager on Linux, I can just install tcl to compile tcltk2 on non-flatpak Rstudio. But Flatpak does not work like that, the flatpaked app does not interact with system installed package. So I will think what to do, either just maintain the regular Rstudio package on the distro repository or try to make RStudio flatpak work somehow.

What you could do is compile the relevant r packages against the same runtime as rstudio flatpak and distribute the compiled packages instead of the sources on cran, just like with windows or osx. That would mean it wouldn't have to rely on gcc and stuff.

Or you could even compile them and put them on flathub as plugins, much like GIMP and a couple of other packages do. But that would mean an extra step of publishing updates on flathub for the plugins too I suppose.

[salim-b]

What you could do is compile the relevant r packages against the same runtime as rstudio flatpak and distribute the compiled packages instead of the sources on cran, just like with windows or osx.

CRAN only provides prebuilt binary versions of packages for Windows and macOS. On Linux distributions, they must be installed from source unless alternative CRAN repository URLs like the ones from RStudio Public Package Manager are used (for Ubuntu 20.04 for example, the URL is https://packagemanager.rstudio.com/all/__linux__/focal/latest).

Maybe the people responsible for RStudio Public Package Manager could be convinced to simply add the RStudio Flatpak runtime as another package build target and introduce a corresponding package repository URL like https://packagemanager.rstudio.com/all/__linux__/flatpak/latest...?

[ilikegitlab]

Rstudio is a developer tool. You are advocating that we should not be able to compile things from rstudio anymore?

Unless the tool is fixed, I think flatpaks are just the wrong tool for solving the problem.

[ludvigng]

Rstudio is a developer tool. You are advocating that we should not be able to compile things from rstudio anymore?

Unless the tool is fixed, I think flatpaks are just the wrong tool for solving the problem.

I'm very much a novice with R, but I was under the impression that R normally isn't compiled? So what are you compiling in rstudio that isn't the packages then? Does that really have to be a part of the flatpak version of rstudio, or is it just something extra?

Because personally I just want to run R code, and I don't like waiting on packages being compiled. Doing it through a flatpak would mean less time spent waiting on package compilation and less time spent on trying to hunt down dependencies for building packages for me, since these packages could be built against a common runtime environment and downloaded just like they are in the other operating systems, but my use case might not be the norm I suppose.

Either way, I think other IDEs available in flatpak hook into different SDK-runtimes (and extensions) to solve this problem. So it should still be able to keep the possibility of compiling stuff if that's really what's wanted.

[ilikegitlab]

This starts to be too much a discussion of our own personal wants and needs, so i'll be brief:

I may be developing packages? Someone has to do that. Any many R packages (no i do not have numbers sadly) depend on Fortran on C for speed. Even in my higher level data-analysis work I regularly call C for time-critical steps.

I've never had to "wait" much more than a few minutes. But if you rely on compiled packages, I guess someone also needs to compile and package all dependencies for those packages. Seems like maintainability hell to me. And that was the point of the original issue. Maintaining 5 distros was cumbersome. Now we are talking about packaging all of CRAN....

[ludvigng]

This starts to be too much a discussion of our own personal wants and needs, so i'll be brief:

I may be developing packages? Someone has to do that. Any many R packages (no i do not have numbers sadly) depend on Fortran on C for speed. Even in my higher level data-analysis work I regularly call C for time-critical steps.

Sure, that's a fair point. Perhaps that could be solved by bundling those dependencies as separate Sdk runtime extensions then for the flatpak? Like the other IDEs seem to do?

I've never had to "wait" much more than a few minutes. But if you rely on compiled packages, I guess someone also needs to compile and package all dependencies for those packages. Seems like maintainability hell to me. And that was the point of the original issue. Maintaining 5 distros was cumbersome. Now we are talking about packaging all of CRAN....

For a single runtime environment, yes. It'd pretty much be like building them for osx or windows. But yes, it would be an added burden, but in exchange linux users wouldn't have to go manually hunting for dependencies by reading the compilation errors like we currently do.

[salim-b]

But if you rely on compiled packages, I guess someone also needs to compile and package all dependencies for those packages.

Yes, CRAN already does this for Windows and macOS. RStudio Public Package Manager does this also for 11 (!) different Linux distros. If I'm not mistaken, they do this for all CRAN packages.

But we have to differentiate between two different types of system dependencies:

1. Ones that are only needed during installation of source R packages. An example is the DEB package libarchive-dev required on Debian/Ubuntu to install the source version of the R package archive.

2. Ones that are always required to use an R package (i.e. during runtime), regardless whether directly installed from a precompiled binary version or a source version of the package. An example would be the R package rJava which obviously requires a working JRE on the system.

If all CRAN packages could be made available as precompiled binary packages (e.g. via RStudio Public Package Manager), a Flatpak version of RStudio could work for a lot of use cases, I guess. Installing R packages from source with Flatpak RStudio would only be a problem for those R packages that rely on low-level C / C++ code and libraries anyways.

The system dependencies that are needed during runtime of R packages (type 2 above) could be made available as Flatpak SDK extensions like @ludvigng suggested above, I guess. At least this is what the VSCodium Flatpak does.

Note that for the Snap package format, there's a different approach available: Applying for "classic" confinement to completely disable sandboxing (thus allowing access to all system resources) and – if granted – users could simply install the snap via sudo snap install rstudio --classic (various dev tools like golang, node.js etc. are available that way).

[znmeb]

Isn't there an R Consortium project for developing R binary objects? https://r-hub.github.io/rhub? It looks like it just does R packages now, but perhaps they could build Flatpak runtimes similar to the Rocker line of Docker images if funding could be created for the project.

[jbingram]

Is it possible to have the core as Flatpak, and let packages be installed afterward as optional Flatpak add-ons/extension (https://github.com/flatpak/flatpak/wiki/Extensions). VLC is using this approach (see below) and there is a similar plan to do the same on Octave which is a Matlab clone with also tones of packages (flathub/org.octave.Octave#134). See image below for VLC