Update R version?

[jonthegeek]

It looks like the WEBR_R_VERSION is hard-coded in R/version.R (currently as R 4.4.1). That means any packages used in apps need to be built for that R version, even though https://github.com/r-wasm/actions/tree/main/build-rwasm currently builds using R 4.5.1, and finding the 4.4.1 tag was a bit of a chore (webr-image: ghcr.io/r-wasm/webr:v0.4.2 for anybody reading this trying to solve the same issue).

Digging a bit more, it looks like the posit-dev/shinylive release has a fixed webr release wrapped into it, which has been 0.4.2 (= R 4.4.1) for about 11 months now. I strongly suspect that means that it'd take quite a lot to change the R version. It would be helpful if that were more obvious, at least, and perhaps if the webr version were noted somewhere prominent to make it easier to figure out how to keep package builds synced to the expected R version.

[gadenbuie]

WIP: posit-dev/shinylive#212

[jonthegeek]

Would it be possible to make the webr-image (eg ghcr.io/r-wasm/webr:v0.5.5, or at least 0.5.5) associated with a shinylive::assets_version() more obvious? I need the package-builder portion of my pkgdown script to match the version used in shinylive, and that's still difficult even after this update (leaving the webr-image field of r-wasm/actions/build-rwasm@v2 at the default will only be valid while both shinylive and the default are on R 4.5). Something like shinylive::webr_image() or shinylive::webr_version() or shinylive::assets_version("webr") would be amazing.

[willgearty]

@jonthegeek you should be able to fix the assets version when you export the app. For example, you can use the currently most recent shinylive assets with shinylive::export("myapp", "site", assets_version = "0.10.6"). You could then fix the webr version based on the changelog. Of course, this would mean you would need to manually update these values every time there is a new shinylive assets release, but maybe this is a good stopgap until your above suggestion is implemented?

[jonthegeek]

@jonthegeek you should be able to fix the assets version when you export the app.

I'm not actually exporting an app in this exact case. I'm (re)building a package and using shinylive in an article on its pkgdown site. This is the workflow line that I need to be able to synchronize with shinylive: https://github.com/shinyworks/chains/blob/main/.github/workflows/pkgdown.yaml#L55

I'll probably pin a shinylive version for it (rather than having to manually update when shinylive updates on CRAN), but it'd be convenient if I could more-easily sync those values.

FYI: This is the article that uses shinylive + the current version of the {chains} package.

[willgearty]

Ah, well, I guess that won't work then. But {chains} looks super useful! I think it will solve one of the problems I'm having with one of my own shinylive projects.

[jonthegeek]

Ah, well, I guess that won't work then. But {chains} looks super useful! I think it will solve one of the problems I'm having with one of my own shinylive projects.

Thanks! That's very much a side project right now, but I'm hoping to actually use it in a couple places and make sure it's as useful as I think, and, if so, push toward CRAN. Let me know if you try it out and it scratches an itch!

[gadenbuie]

@jonthegeek there's also a SHINYLIVE_ASSETS_VERSION that you can use to set the version for shinylive assets used that you could set in your workflow. That would help if the pkgdown site building needs to use a specific version of shinylive.

[jonthegeek]

@jonthegeek there's also a SHINYLIVE_ASSETS_VERSION that you can use to set the version for shinylive assets used that you could set in your workflow. That would help if the pkgdown site building needs to use a specific version of shinylive.

I guess I could use that to effectively pin the shinylive version without pinning the shinylive version. That should work for now. Thanks!

[gadenbuie]

pin the shinylive version without pinning the shinylive version

That's a tongue twister!