Update webR to run R 4.4: can't install packages from a custom wasm CRAN built with R 4.4

[DivadNojnarg]

I am maintaining a wasm CRAN-like which was build from GA with R4.3 few weeks ago using the r-wasm/actions flow from @georgestagg: https://github.com/RinteRface/rinterface-wasm-cran.

I updated it and since R4.4 was released recently, my WASM repo is now built with R4.4. shinylive depends on an older webr version (webR only supports R4.4.0 since recently r-wasm/webr@28077f5). Therefore, shinylive still runs R4.3 (there are references to R4.3 such as in webr::install):

webr::install
function (packages, repos = NULL, info = NULL, lib = NULL, quiet = FALSE, 
    mount = TRUE) 
{
    ...
    contrib <- gsub("repo.r-wasm.org/bin/emscripten/contrib/4.3", 
        "repo.r-wasm.org/bin/emscripten/contrib/4.3.3", contrib, 
        fixed = TRUE)
...
}

getRversion()
[1] ‘4.3.3’

which prevents from retrieving and installing the package from my CRAN like.

Here is the shinylive link to reproduce.

[georgestagg]

Hi,

Thank for for reporting this! Indeed, your analysis looks correct. The r-wasm/actions scripts currently track the latest build of webR, rather than some fixed version, and Shinylive is currently fixed to use version v0.3.1 of webR.

Eventually, a version of webR will be released running R 4.4.0, we'll update Shinylive to match, and this will go away. However, I can see this will be an issue up until that point, and also going forward for users with older Shinylive deployments already in place.

So, I have opened a PR in r-wasm/actions with a potential solution at r-wasm/actions#20. With that change, the user will be able to choose which webR development image to use. By choosing to build packages with the webR v0.3.1 image explicitly, R packages will be built under .../bin/emscripten/contrib/4.3/, compatible with that version of webR.

Once that PR has been cleaned up and merged, you should be able to make use of the new workflow input in your GitHub Actions file to solve this Issue. I will come back here and document the process in more detail at that point.

[georgestagg]

I've merged r-wasm/actions#20, which allows the user to select the webR image version when building R packages for Wasm.

In .github/workflows/deploy.yaml, update your deploy-cran-repo job to point to the webR v0.3.3 image using the webr-image parameter, e.g.

  deploy-cran-repo:
    uses: r-wasm/actions/.github/workflows/deploy-cran-repo.yml@v1
    with:
      webr-image: "ghcr.io/r-wasm/webr:v0.3.3"

That particular fixed version of webR is running R v4.3.3, and so the R packages compiled for wasm will be built into the repo directory /bin/emscripten/contrib/4.3.

Hopefully, this should allow the repository to be used with Shinylive and fix the issue. Please let me know if not!

[DivadNojnarg]

@georgestagg I tested yesterday on the pkgdown website demos and a blog post with shinylive chunks. This seems to work well.

[DivadNojnarg]

@georgestagg This seems broken again since the latest shinylive update. You can test with this link https://blockr-org.github.io/blockr/ which was build using older webR assets: https://github.com/blockr-org/webr-repos/blob/main/.github/workflows/deploy.yml#L18. But shinylive still complains about Warning: unable to access index for repository https://blockr-org.github.io/webr-repos/bin/emscripten/contrib/4.4 looking for R 4.4 folder. Is there a new configuration parameter for shinylive to set the R version or does this mean I have to host my own shinylive app with frozen R version?

[georgestagg]

Shinylive has been updated and is now using the latest release of webR. So, you should remove the change we discussed above that added the webr-image parameter. Then, by default, the latest version of the webR image will be used to build your CRAN-like repository. That way, the /4.4 directory will be created as expected.

In general this is likely to continue to happen as Shinylive and R are updated over time.

It is possible to freeze the Shinylive and R package versions in place, but to do that you’ll need to use the Shinylive R package to export the app, and then host the resulting static assets somewhere, rather than using an iframe embed of the Shinylive website. See here for more information about the Shinylive R package.

[DivadNojnarg]

Thx! For the code export, I guess I can wait for posit-dev/r-shinylive#92 to have a more scalable option, as I'd like to automate the process.