Skip to content

Roadmap for R package ecosystem

Ken Williams edited this page May 3, 2019 · 1 revision

Here are things I'm working on, toward the goal of specifying package dependencies and having those specifications fulfilled. My focus is particularly on managing the R ecosystem in "enterprise" environments, but the tools are applicable everywhere, and hopefully will benefit everyone.

My organization is using Sonatype Nexus and its experimental R for artifact management, which is very convenient because it's the same artifact infrastructure we use for Java, Python, Javascript, and so on. It also enforces certain semantics, e.g. that once an artifact with a certain name and version are uploaded, it cannot be changed, and no future artifact can have that same name and version.

1. Users should be able to query the versions of a package available in a CRAN-like repository

In CRAN itself, when a new package is published with a new version, the previous version moves to an Archive/ directory, and an index of those packages is available in the Meta/ subdirectory as the archive.rds file.

In Nexus, the archive.rds file isn't available (because Nexus is Java code, not R code, and RDS is an R format), so clients can't request it in order to peruse available versions. I've created a small library (https://github.com/focusenergy/JavaRDS) that allows creation of RDS files from Java, in hopes that it can be integrated into the Nexus R plugin.

2. Developers should be able to share development snapshots with others

One way to share work-in-progress with other developers is to point them to your Git repository and tell them to install whatever's on the develop or master branch or whatever. Sometimes that's fine, but I don't love it because

At my organization, we publish all pushes to develop to a "dev" repository. The version number in the DESCRIPTION file gets an increasing number appended to it (in our case, the build number from our CI/CD system).

...work in progress...