docs(r/adbcbigquery,r/adbcflightsql,r/adbcsnowflake): recommend to install from R-multiverse

[eitsupi]

Close #1647

In the short term, CRAN is unlikely to accept Go-based packages, so for now we can recommend installation from R-multiverse.

We can also use the ASF repo of R-universe (https://apache.r-universe.dev/), but R-multiverse is more reliable because it is tied to the latest release with certainty.

Note that adbcbigquery has not been added to R-multiverse yet (r-multiverse/contributions#213 will be merged after ADBC 15 release)

[paleolimbot]

Thank you!

[sounkou-bioinfo]

Dear @eitsupi @paleolimbot,
Adding a comment to this issue,
i ve recently submitted a go using package to CRAN and it was archived because of some warnings and of interest arrow case is the build failure on windows. I have submitted a question on r-package-devel mailing list https://hypatia.math.ethz.ch/pipermail/r-package-devel/2025q4/012067.html and the feedback was as follow

Sounkou,

as usual, you should start with the instructions in "External Libraries for CRAN packages"[1] which really boils down to sending an e-mail to CRAN and CCing me and Uwe. That is assuming that produced Go binaries are self-contained and don't need a run-time. If that's not the case, then it gets a lot more complicated as it would require static run-time built with R tools and that may complicate Windows support substantially (since MXE doesn't have Go AFAICS, you'd have to ask Tomas). In the simple case we can install toolchains on the build machines if they are officially available and compatible. The latter is an issue here as you pointed out so it may be worth discussing that. We may want to test things first before rolling it out.

The way I see it, given the constraints in Go, it would be worthwhile to write something like an "Rgo" package that is the only Go runtime and any R package that wants to add Go code would use it to load its code as Go plugin. This is in concept similar to other languages like Python (reticulate) or Java (rJava) where you always load only one run-time and then simply use the corresponding language-provided loading mechanism to load any additional code/modules. This is just based on a cursory glance, so Go enthusiasts may want to comment on the feasibility.
Cheers,
Simon
[1] https://cran.r-project.org/web/packages/external_libs.html

As it appears that the adbc go using drivers are using the c-shared buildmode, i wondered if this is the reason the packages where not submitted to CRAN and if anybody ever encountered this issue golang/go#65050. In my use-case since i can avoid using cgo by reworking the package, therefore i may be requesting the a simple go installation on the windows machine.

For the other "Rgo" suggestion, i wondered if there are any plans/appetite for this. And feeback from go enthusiasts is highly welcomed.

Best wishes

[eitsupi]

Thanks for the info!

I think there was a similar discussion about Rust before, but I think something like rgo is really unnecessary and what's needed is a proper installation of Go on the CRAN machines. (As an aside, Rust is now installed, but there are frequent issues with version updates.)

Personally, I don't want to put in a lot of effort to submit to CRAN because R-multiverse works well.

[paleolimbot]

Cool! I sent a note on the R package dev mailing list about the Go issue with details of the adbcsnowflake submission that I abandoned some time ago. We've never had requests for CRAN distribution and so I assume the R-multiverse is working (or nobody uses the R package!).

if anybody ever encountered this issue golang/go#65050.

Yes, we encounter it on MacOS intel when using multiple go-based ADBC drivers at once but haven't since. The same issue in theory occurs for the Python versions of these drivers (which are used more widely) and we haven't seen user reports of crashes or excessive memory usage of which I'm aware.

[eitsupi]

I assume the R-multiverse is working (or nobody uses the R package!).

I've only seen it in use once 🙂
https://zenn.dev/dataheroes/articles/snowflake-r-arrow-format#1.-rstudio%E7%92%B0%E5%A2%83%E3%81%A7%E3%81%AEadbc%E8%A8%AD%E5%AE%9A

[sounkou-bioinfo]

Dear @eitsupi @paleolimbot, Adding a comment to this issue, i ve recently submitted a go using package to CRAN and it was archived because of some warnings and of interest arrow case is the build failure on windows. I have submitted a question on r-package-devel mailing list https://hypatia.math.ethz.ch/pipermail/r-package-devel/2025q4/012067.html and the feedback was as follow

Sounkou,
as usual, you should start with the instructions in "External Libraries for CRAN packages"[1] which really boils down to sending an e-mail to CRAN and CCing me and Uwe. That is assuming that produced Go binaries are self-contained and don't need a run-time. If that's not the case, then it gets a lot more complicated as it would require static run-time built with R tools and that may complicate Windows support substantially (since MXE doesn't have Go AFAICS, you'd have to ask Tomas). In the simple case we can install toolchains on the build machines if they are officially available and compatible. The latter is an issue here as you pointed out so it may be worth discussing that. We may want to test things first before rolling it out.
The way I see it, given the constraints in Go, it would be worthwhile to write something like an "Rgo" package that is the only Go runtime and any R package that wants to add Go code would use it to load its code as Go plugin. This is in concept similar to other languages like Python (reticulate) or Java (rJava) where you always load only one run-time and then simply use the corresponding language-provided loading mechanism to load any additional code/modules. This is just based on a cursory glance, so Go enthusiasts may want to comment on the feasibility.
Cheers,
Simon
[1] https://cran.r-project.org/web/packages/external_libs.html

As it appears that the adbc go using drivers are using the c-shared buildmode, i wondered if this is the reason the packages where not submitted to CRAN and if anybody ever encountered this issue golang/go#65050. In my use-case since i can avoid using cgo by reworking the package, therefore i may be requesting the a simple go installation on the windows machine.

For the other "Rgo" suggestion, i wondered if there are any plans/appetite for this. And feeback from go enthusiasts is highly welcomed.

Best wishes

Thank you for the intervention and the explanation of the journey ! At least all of this can be found more easily now. The go 1.21 regression on the issue is a shame (but i guess somebody really need the "performance hack" for go users of). Also great to see that the go runtimes are isolated in the adbc packages !

[lidavidm]

FWIW, it might be possible to fix the Go issue on macOS/Intel, it's just that given that platform is on its way out, it's probably not worth spending the time trying to get something upstream. If it started happening on other platforms a fix would be a high priority though.

[sounkou-bioinfo]

Thanks for the info!

I think there was a similar discussion about Rust before, but I think something like rgo is really unnecessary and what's needed is a proper installation of Go on the CRAN machines. (As an aside, Rust is now installed, but there are frequent issues with version updates.)

Personally, I don't want to put in a lot of effort to submit to CRAN because R-multiverse works well.

Granted that r-multiverse is more convenient bu we should at least get the go compiler on CRAN for the modest use-case of building go binaries for packages that just use executable (or even bootstrap a different go version if needed).

[sounkou-bioinfo]

FWIW, it might be possible to fix the Go issue on macOS/Intel, it's just that given that platform is on its way out, it's probably not worth spending the time trying to get something upstream. If it started happening on other platforms a fix would be a high priority though.

As you may know, it looks like it (may) happen sporadically on other platforms too. But as you probably saw on the issue golang/go#65050, the go core members are very dismissive of the whole thing and the "performance hack" that led to the "regression" because the "intended use" was supposed to be different. They suggest using plugins, but that package is not portable.

[sounkou-bioinfo]

Given these restrictions and the use cases i am targeting, i thought it would be more productive using arrow IPC and other IPC setups, so i made package that uses nanoarrow and nanonext on the R side and mangos and arrow-go on the go side https://github.com/sounkou-bioinfo/mangoro