Our company uses Sonatype Nexus to publish our internal software artifacts, and Sonatype has an experimental R plugin that lets an R package repository function like a bona fide CRAN repository. In general it works pretty well.
One little mismatch: Nexus (like most other artifact repositories) lets multiple versions of R packages coexist in the repo, while CRAN has just the “most recent” (highest version) artifact listed in its
PACKAGES.gz files, and lists previous versions in an
archive.rds file in the src/contrib/Meta/ folder.
- The Nexus R plugin doesn’t know how to generate an
archive.rdsfile (it generates the
PACKAGESindex on the fly in response to HTTP requests);
remotes::install_version()function (which I have a feature branch of here, BTW) only knows how to discover older versions through the
So they don’t play well together on this issue.
I’ve raised a ticket on the plugin’s GitHub queue:
One thing I’m not sure of, though - is there any other mechanism in CRAN-like repositories that Nexus should be emulating to discover other versions of packages than the highest-numbered version? The
archive.rds file seems kind of clunky, needing to download the entire file - for all packages in the repo - just to query for one package. And an RDS file is going to be a bit unpleasant to generate in the Nexus code, because it’s a Java app that doesn’t have R.
Anyone in this forum thought about this issue before?