Package versioning in a test/production environment

Hi everybody!

I have a quick question for the community about package versioning.

I'm setting up a full stack R-based data science delivery platform around Rstudio Server, Connect, and eventually package manager. We use git for code review and pull requests, and push products through a test environement for integration/acceptance testing, and then finally to the production environment.

My question: RStudio Connect in dev/test/prod will look at the same package repository for homegrown packages (either a miniCRAN-like repo, and later Rstudio Package Manager), but will need to use different package versions - i.e. projects in prod needs to use the latest production version, but dev/test might need newer dev versions.

How can this be handled the best way?

Thanks in advance!

Regards
Johannes W

Hi @Jwaage

This seems like a great problem for RStudio Package Manager to help solve. The beauty of Package Manager is that you can have multiple repositories made up of different package sources that then serve multiple or individual environments. You could potentially set up:

  1. A "cutting-edge" development repository fed from a regularly synced CRAN source and internal packages source
  2. A testing/production repository fed from curated (production approved) CRAN packages and your internal package sources

Giving your developers the choice between using the testing/production or the "cutting-edge" repos will could provide a lot of useful flexibility depending on the type of development work they're engaged in. Obviously, it's frustrating to develop an app intended for production on one set of packages, then have to reconcile whether those packages/versions will be available in testing. On the other hand, it's quite useful to have all the latest packages when you're engaged in bleeding edge data science work and POC development.

I believe the latest RStudio Package Manager Webinar goes through the basic repository/source paradigm and a few basic use cases.

Getting familiar with the various change control strategies that RSPM enables as outlined in the docs might also be useful.

1 Like

Great, sounds like RSPM is the solution that will work best in this case, serving multiple repos for the deploy chain.

I think this should be solvable to some extent in open source R as well.

Thanks again

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.