Rstudio: 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?

[msberends]

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

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

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]

your use case is a rather narrow one

We don’t know, now do we :wink:
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 :smile: 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 :wink: You’re obviously a developer, and that’s awesome. Just don’t forget RStudio users use more packages than develop them.

[Enchufa2]

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

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

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

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]

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

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]

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]

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]

@Enchufa2

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

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

[znmeb]

What's the latest on this?

[jmcphers]

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

I understand this is proprietary software

It’s not!

[keberwein]

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]

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]

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]

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

[btreut]

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]

Change

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

to

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

[btreut]

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]

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]

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]

Tanks a lot for the clarifications.

[btreut]

To summarize the status as of Febrary 2019:

Current production release: 1.1.463
Future production pre-release or release candidate/preview: 1.2.1280

If I find the time to re-create yet another flatpak for RStudio, which one should I chose instead of the current master, see also Alexander Wilms' post three weeks ago.

[chriselrod]

I like Stan, so I prefer RStudio v1.2.
Although I'll probably resort to building RStuio Server from source. Lets an old laptop impersonate a powerful workstation when working remotely.

[znmeb]

@btreut Are you building the flatpak from source or from a Linux distro binary package? If it's a package, it's pretty straightforward to poll the RStudio Preview download page every day to see if it's been updated. The source tarball is there too, I think.

@chriselrod There's a Docker image with the RStudio Preview on it - for the server, a container's as good or better than a flatpak - https://hub.docker.com/r/rocker/rstudio-daily

[jmcphers]

it's pretty straightforward to poll the RStudio Preview download page every day to see if it's been updated.

Use this instead: https://www.rstudio.com/wp-content/downloads.json

No guarantees on this link's availability (any more than the dailies site), but it ought to be more machine-readable.

[znmeb]

@jmcphers Thanks! Now I need a JSON parser for bash ;-)

[probonopd]

This thread is mixing all kinds of distribution methods. As someone exclusively interested in one of the three formats, I'd appreciate if we could have separate threads for

Flatpak - https://flatpak.org/
Snapcraft - https://snapcraft.io/
AppImage - https://appimage.org/

Thanks.

[Enchufa2]

This thread is mixing all kinds of distribution methods.

Yes, because this thread was intended to evaluate these technologies for the particular use case of RStudio. Also it may be mixing RStudio users and people that are just lobbying for the solution they created.

[btreut]

Change

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

to

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

I tried that, but now the build fails because it apparently requires Qt5WebKit

[TingPing]

I tried that, but now the build fails because it apparently requires Qt5WebKit

Add:

base: io.qt.qtwebkit.BaseApp
base-version: '5.12' # Matching KDE runtime version used

[btreut]

where should I add it?

I tried to add it after the branch line I added peviously, but this results in the same Qt5WebKit errors:

CMake Error at src/cpp/desktop/CMakeLists.txt:83 (find_package):
By not providing "FindQt5WebKit.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5WebKit", but CMake did not find one.

Could not find a package configuration file provided by "Qt5WebKit" with
any of the following names:

Qt5WebKitConfig.cmake
qt5webkit-config.cmake

Add the installation prefix of "Qt5WebKit" to CMAKE_PREFIX_PATH or set
"Qt5WebKit_DIR" to a directory containing one of the above files. If
"Qt5WebKit" provides a separate development package or SDK, be sure it has
been installed.

-- Configuring incomplete, errors occurred!
See also "/run/build/rstudio/CMakeFiles/CMakeOutput.log".
See also "/run/build/rstudio/CMakeFiles/CMakeError.log".
Error: module rstudio: Child process exited with code 1

[Alexander-Wilms]

You'll need to add - -DQt5WebKitWidgets_DIR=/app/lib/cmake/Qt5WebKitWidgets to the config-opts of the module rstudio

[btreut]

hmm, I added it, but this does not change the error message.

[Alexander-Wilms]

You could switch to the git tag v1.2.1320, since which RStudio uses QtWebEngine, which is already included with the KDE SDK.

[btreut]

I tried it with v1.2.1320 and v1.3 but I get errors, which I do not understand, so I give up

[probonopd]

Another request for an AppImage:
https://github.com/rstudio/rstudio/issues/1967#issuecomment-473384701

[11rchitwood]

Looks like Microsoft went with snap for vscode in their official build.

[casperl]

And a kind request for a snap package - targeted system Ubuntu 19.10.

[btreut]

I did not realize until today that RStudio came out with v1.2.1335 on Apr/8/2019. So I will try to recreate a flatpak for this version (see my earlier post of Mar, 14th and before above).

[btreut]

my attempts to recreate a flatpak for the released RStudio with the released version failed miserably.

@jmcphers
is there any progress with a decision about adopting flatpak/snap/appimage for RStudio?

[probonopd]

Check https://github.com/adnion/RStudio.AppImage/releases/tag/master

[bryanpaget]

I'm running Fedora Silverblue and Rstudio is the only app I can't install... I think flatpaks and snaps are less messy that Appimages since they integrate with the OS and have their own "stores". Once you get the app on flathub or snapcraft, it's so easy for end users to install.

[probonopd]

And I think AppImage is _less_ messy because it does _not_ integrate with the OS and does _not_ need centralized stores... one app = one file, no package manager needed. Simple!

[msberends]

@probonopd yes, you said that numerous times now. Point well made. Are you being paid by AppImage investors or so??

Like said previously too, 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. Out of the box (so without other packages), AppImage requires this and is consequently not convenient at all. Not everyone likes it, you know.

[probonopd]

Are you being paid by AppImage investors or so??

I am the main investor. I am investing my time in it.

[wilx]

Is it really necessary to pick just one? I understand resources are limited but once you are set up to build any of these, how much effort is it to maintain each of the distributions? You will/should have this mostly automated anyway, so I think, it should be possible to provide all of them.

[felipeborges]

@btreut could you publish your failing flatpak manifest somewhere so someone could pick it up from where you stopped?

[btreut]

@btreut could you publish your failing flatpak manifest somewhere so someone could pick it up from where you stopped?

I do not remember exactly which iteration is the one in the zipped yaml, since I have been experimenting a bit:
RStudio-yaml.zip

@felipeborges thanks for taking care of it, I was getting lost in the maze of yaml & flatpak-builder ...

[ignacio82]

@jmcphers is RStudio abandoning the effort for creating a snap (or similar)?

[kevinushey]

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.

[btreut]

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.

sorry to read this, but hopefully felipeborges and collegues will succeed in creating an usable flatpak (it is work in progress, see https://github.com/HarryMichal/rstudio-flatpak).

[cribari]

If there is a vote, my preference would be for Flatpak.

[btreut]

Enchufa2 asked on Dec 26, 2018: Why is it so big compared to other bundles?

hmm, in the mean time, I tried to install RStudio (and R of course) in a toolbox container running fedora 29 without success since some dependency could not be resolved correctly. The fact that the RStudio flatpak packs R and installing R alone pulled already 390+ packages might explain the size of the RStudio flatpak.

[Enchufa2]

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.

[Enchufa2]

And before me, openSUSE did the same. @dcermak is the maintainer of the RStudio rpm for openSUSE.

[branchus]

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]

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]

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]

is that 2020 ?

[btreut]

is that 2020 ?

what?

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

[eoli3n]

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]

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

[casperl]

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]

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]

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]

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

[btreut]

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]

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]

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]

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]

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]

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]

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]

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.