[Feature Request]: working dev module install on flatpak

[tomtomme]

JASP Version

0.19 beta from yesterday

Commit ID

9d89aae2e4119b5cc0c6083a0f1fcc035abb1633

What analysis are you seeing the problem on?

Dev Module install

What OS are you seeing the problem on?

Flatpak

Bug Description

The installation of Module jaspModule failed with the following errormessage:
Error: Error in setupRenv(moduleLibrary, modulePkg): A cache is supposed to be at '/app/bin/Modules/renv-cache' but it does not exist!

tryCatch(suppressWarnings({
    returnVal <- eval(parse(text = .rCode))
}), error = function(e) {
    .setRError(paste0(toString(e), "\n", paste0(sys.calls(), collapse = "\n")))
})
tryCatchList(expr, classes, parentenv, handlers)
tryCatchOne(expr, names, parentenv, handlers[[1]])
value[[3]](cond)

Steps to Reproduce

I followed:

Steps to add the module folder as a development module in JASP:

Open JASP
Click on the menu in the top left corner
Navigate to 'Preferences'
Navigate to 'Advanced'
Place a checkmark before 'Developer mode'
Browse to the module source folder, aka a folder with the same name as your module and that contains inst/Description.qml.

Steps to install the module in JASP:

Open JASP
Click on the plus symbol in the top right corner
Click on Install Developer Module

then the error message appears

[github-actions[bot]]

@tomtomme, thanks for taking the time to create this issue. If possible (and applicable), please upload to the issue website (https://github.com/jasp-stats/jasp-issues/issues/2588) a screenshot showcasing the problem, and/or a compressed (zipped) .jasp file or the data file that causes the issue. If you would prefer not to make your data publicly available, you can send your file(s) directly to us, [email protected]

[RensDofferhoff]

The dev modules not working on flatpak is a known issues and we did not plan on resolving it (or it is very low priority). Instead resorting to compilation of JASP on linux. Unless you changed you mind on this @JorisGoosen .

[JorisGoosen]

Yeah getting it to run on flatpak would probably be a bit hard and for little gain.

Compiling JASP yourself could work or using (if on arch/manjaro) the AUR package. (Which ive never used though)

[RensDofferhoff]

I considered making an appimage recently but its as you say, a lot of work for little gain.

[JorisGoosen]

Yeah and I kind of assume that people working on linux can be trusted to compile JASP? Which is not even all that painful if one turns on JASP_TEST_BUILD as a cmake option and JASP_TEST_MODULE with the name of the module they want to work on.

[RensDofferhoff]

It can be on ubuntu LTS and old installs with no updates. But on manjaro or fedora its only slighty tricky

[tomtomme]

Interesting! I would bet that I have used the dev module in the past (some years ago) on flatpak. But maybe I used windows just for that...or I compiled it. So yeah, I will compile then.

But then again... this guide says, that I could do this with flatpak: https://github.com/jasp-stats/jasp-desktop/blob/stable/Docs/development/jasp-module-workflow.md

The Linux section should be updated then from "use flatpak" to "please compile

[RensDofferhoff]

good point let me do that now.

[RensDofferhoff]

Altered the doc. The difficulty with getting flatpak to work lies in the sandboxing of a flatpak. Maybe I could get it to work but it is low priority. We could change this issues into a feature request?

[JorisGoosen]

@RensDofferhoff isnt it maybe just a moved renv-cache location? A cache is supposed to be at '/app/bin/Modules/renv-cache' sounds like that tbh

Where is the renv-cache really? Maybe thats all you need to change. (And perhaps running JASP with --devel)

[RensDofferhoff]

/app/lib64/renv-cache/v5/ I can try that real quick tomorrow. If it is that easy then great

[Joao-O-Santos]

First off, once again, let me thank you for all you're doing for open source and stats more generally with JASP. Thank you also for supporting Linux, and having a detailed build guide.

Apologies for meddling in your conversation, but as I opened a related issue yesterday (#2586 ), I feel I should comment on a couple of points more related to building from source on linux than to flatpak installs.

Compiling JASP yourself could work or using (if on arch/manjaro) the AUR package. (Which ive never used though)

It's obviously possible to compile JASP on Linux, but I wouldn't call it the simplest process. I'm not a developer by trade, but I've been running Linux for years, and I've compiled software from source before, and I would not list this as the simplest install. Please understand I do not mean this as a destructive criticism, JASP is a modern piece of software with many dependencies and cross-platform support, one should expect it to take a little more work to compile than say a simple cli tool. Still, the thing is some system dependencies (for both jaspBase and other modules) seem to be missing from the guide, at least for Arch Linux based distributions (I tried to write up what I found in #2586 ). In my issue (#2586 ) @tomtomme pointed me to some pull requests I believe are related to the flatpak build, and/or to testing JASP builds on Ubuntu through github actions. I'm not sure, but maybe some of those dependencies got added to the github actions but not to the build guide.

Yeah and I kind of assume that people working on Linux can be trusted to compile JASP? Which is not even all that painful if one turns on JASP_TEST_BUILD as a cmake option and JASP_TEST_MODULE with the name of the module they want to work on.

@JorisGoosen I understand where you're coming from, but that depends if you're talking about users or developers, and even then about the developers' background. People can be experienced R programmers, even developing packages, without having much experience with cmake and/or ninja for instance. The same can be said of stereotypical Linux greybeards who may be more used to GNU tooling. Moreover, your Linux build guide states it might be simpler to use QtCreator to configure the compilation. I reckon this assumes yet another kind of developer, one familiar with QtCreator (but not necessarily with using cmake on the command line, or other tooling).

If you're talking about regular Linux users, not developers, then I think the situation might be worse. For instance, arch linux users might be used to installing software from the aur, but they may install it with a aur helper or without reading through the PKGBUILD. In fact, I tried installing from the aur and I had to read up your linux build guide, plus a user comment from the aur, plus debug missing system packages. Besides, the aur build builds JASP in way that it expects every module to be present, and the aur package itself list many JASP modules as dependencies but not all. The packages themselves needed to be installed from github (devtools::install_github()) and the ones on CRAN were incompatible with the version of R I had installed (with Arch derivatives it will tend to be a recent version of R). This triggered github's rate limiter, and you explain this can be overcomed by setting GITHUB_PAT, but the aur build sets that to none given it can't guess users' github tokens nor assume every user will have one.

Please understand, I do not mean to bring negativity into the lives of those doing so much for open source and stats, nor to make supporting Linux and its community a pain. I think this is fixable by adding any missing dependencies and maybe some other revisions to the build guide. It would also be amazing if you supported the aur package (and/or ppa for debian based distros) more directly. What would be perfect is if you got JASP into a distro's official repos. I understand any of these changes might lead to a great workload without many expected rewards. This is me dreaming not demanding.

Please do let me know if there's anything I can do to help. I'm just starting to use JASP because I'll be teaching with it, but I have some experience with R and Linux.

[RensDofferhoff]

@Joao-O-Santos Hi thanks for the feedback don't worry about sounding negative.

I partly agree Jasp is not the easiest to compile. And people inclined to work on an open source project might favor Linux more often than our general user base.

We should either make it easier (for example by providing a docker container that contains the build system) or taming the huge amount of dependencies.

Or we should get development modules working on flatpak beta branch. That way the majority of developers can tinker around freely.

Or both.

It is a bit busy right now but I will schedule some time to tinker around tomorrow. I'm a Linux user myself so I would really like to have it working.

[RensDofferhoff]

I'm not sure about maintaining aur, ppa, etc though. The amount of work spirals quickly. In this regard flatpak is great.

[JorisGoosen]

Well, I do hope flatpak will work. I wrote that original manual so Im assuming flatpak did at some point support installing development modules. But I dont really remember anymore.

The development modules, and the support for JASP Modules as R-packages more generally, were of course initially implemented exactly because of all the problems @Joao-O-Santos lists. He is right of course that we can't expect users to build jasp from scratch. Its more that it is more of a workaround on linux than it would be on windows or macos.

If only because linux users are more likely to even know what compiling means.

Ideally of course one can just install development modules in JASP in flatpak. I think it is possible to make it work in any case.

However, if @Joao-O-Santos notices any missing dependencies in our documentation than I would very much welcome a PR with some additions ;)

[RensDofferhoff]

@JorisGoosen what do you think of the docker idea. I see a bunch of docker-ized buildsystem in other open-source projects.

[JorisGoosen]

the docker idea would make it very easy to run and develop for JASP. And it would automatically avoid problems with any local installs.

It sounds rather appealing actually

[Joao-O-Santos]

I'm not an expert on snaps vs flatpaks vs docker vs podman. But a flatpak sounds like the way to go for end users if you don't want to maintain a binary package on any distro.

But if you're talking about maintaining a Dockerfile yourselves, I'm not sure it'll be any easier. My experience with docker tells me you'd have to install all system dependencies in the container and automate the install without user input.

If you notice that is not too far from what it would take to fix the documentation bug ( #2586 ) and probably the flatpak as well.

It could be a way of validating the install documentation and you could copy paste from the Dockerfile to the build guide, and vice-versa, but I don't think it'll save you much work.

Besides you'd probably run into the same problem with GitHub's rate limiter, as I don't think you'll want a public Dockerfile to have anyone's token.

[Joao-O-Santos]

Having said this, I'll try to submit a pull request for the documentation.

It would be cool if you could include one or two examples of cmake and ninja commands for how to build JASP.

I'm more of a (GNU) Make guy myself, so I can't do that part, but I can test what you write.

Do note that this is not very different from what you'd have to do for a Dockerfile unless you just unpack pre-packaged files into directories or other Dockerfile hacks.

[tomtomme]

@RensDofferhoff @JorisGoosen This old issue proves, that it worked on flatpak 2 years ago: https://github.com/jasp-stats/jasp-issues/issues/1659

It also mentions the same error message about the cache - but that one was not solved.

[RensDofferhoff]

Working on it!

[tomtomme]

with current beta I get a new error message:

The installation of Module jaspModule failed with the following errormessage:
Error: Error: .onLoad failed in loadNamespace() for 'renv', details:
  call: if (renv_path_within(cache, getwd())) {
  error: the condition has length > 1

tryCatch(suppressWarnings({
    returnVal <- eval(parse(text = .rCode))
}), error = function(e) {
    .setRError(paste0(toString(e), "\n", paste0(sys.calls(), collapse = "\n")))
})
tryCatchList(expr, classes, parentenv, handlers)
tryCatchOne(expr, names, parentenv, handlers[[1]])
value[[3]](cond

[boutinb]

I have heard from @vandenman that renv has a new version, and makes the dev module crashes...

[vandenman]

Yes, https://github.com/rstudio/renv/commit/d5b7e6ad4bf844dbe0c6535230747a1d75c5cf4b should fix this error. I don't know when the fix will land on CRAN though. We could also just merge https://github.com/jasp-stats/jasp-desktop/pull/5438 until then (and revert it afterward).

[tomtomme]

We have a duplicate report now here from rcalinjageman who would like to work on a module: https://github.com/jasp-stats/jasp-issues/issues/2249 So a quick fix for the next nightly would be cool.

[EJWagenmakers]

Agreed, this is important!

[Joao-O-Santos]

Don't know if this helps but if the if(...) statement is in your code base and the error is due to the logical test inside it returning multiple values sometimes a quick fix would be to wrap the statement in any() or all() or figuring out if you just want the first value and subseting the result with [1].

That's assuming the values returned by the buggy renv version still make sense but are of length > 1.

Please ignore if this doesn't make sense for your use case. Just trying to help and major thanks for supporting Linux.

[JorisGoosen]

Thanks @Joao-O-Santos but that is renv's code that simply doesnt know how to handle our totally intentional list of 2 cache locations.

That code is also what Don fixed in https://github.com/jasp-stats/jasp-issues/issues/2588#issuecomment-1985718704

Hope we get it fixed for jasp soon though :)

[tomtomme]

if of any help: current error message with 0.19 beta

The installation of Module jaspModule failed with the following errormessage: failed to resolve remote 'jasp-stats/jaspBase' -- error downloading 'https://api.github.com/repos/jasp-stats/jaspBase' [error code 56] value[3] tryCatchOne(expr, names, parentenv, handlers[[1]]) tryCatchList(expr, classes, parentenv, handlers)

-------- Application Info -------- JASP Version: JASP 0.19 Build Branch: HEAD Build Date: May 23 2024 21:22:50 (Netherlands) Last Commit: 2f53f98b336720bfb44241df4145741a46b1d75e

-------- Basic Info -------- Operating System: KDE Flatpak runtime Product Version: 6.7 Kernel Type: linux Kernel Version: 6.8.9-3-MANJARO Architecture: x86_64 Install Path: /app/bin System Local: de_DE

[RensDofferhoff]

Working on it now. Since we are moving to a lockfile based system