[R-pkg-devel] CRAN Policy on Go using Packages

[Simon Urbanek]

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



> On Oct 18, 2025, at 15:35, Sounkou Mahamane Toure <sounkoutoure using gmail.com> wrote:
> 
> Dear All,
> 
> 
> I have recently submitted a Go using Package to CRAN and it was
> archived (i have yet to receive the rejection email).
> 
> I have anticipated the warnings (at least on Unix) and made comments
> during the submission. A pointer from Ivan Krylov around the potential
> of crashing R in the case of loading multiple go buildmode c-shared
> loaded in the same process suggests that my comments may have been
> misguided (even though I used the c-archive mode).
> 
> I figure for the fairly limited use case and the existing design
> strategy of limiting communication between the go and C runtime to
> pipes, I can execute an external go process instead. One issue remains
> tough, is that in order to build this binary at installation time, a
> golang toolchain is required.My package failed on win-builder on
> windows because go was not found on the PATH of that machine. And as
> it happens that shipping with the package pre-built cross-compiled
> binaries like it is done in the  pmtiles  package is not advisable,
> options become limited.
> 
> Krilov also referenced the case of the adbcbigquery and allied
> packages that are likely published on r-multiverse instead of CRAN for
> similar reasons.
> 
> It would be great if CRAN were to clarify its views on go using
> packages and the toolchain.
> 
> 
> Thank you in advance
> 
> Best regards,
> 
> Sounkou Mahamamane Toure
> 
> References :
> 
> The check on debian can be found here :
> https://win-builder.r-project.org/incoming_pretest/goserveR_0.1.3_20251005_222222/Debian/00check.log
> 
> golang c-shared restrictions : https://github.com/golang/go/issues/65050
> 
> The check on windows :
> https://win-builder.r-project.org/incoming_pretest/goserveR_0.1.3_20251005_222222/Windows/00install.out
> 
> pmtiles builder of cross-compiled binaries :
> https://github.com/walkerke/pmtiles/blob/5fcd3082bb21d5f442d458c42d5165c64c1cf173/tools/build_binaries.sh
> 
> arrow-adbc issue : the https://github.com/apache/arrow-adbc/pull/2262
> 
> [[alternative HTML version deleted]]
> 
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>