I am using renv to collaborate on an R projects with my colleagues. This seems to work qute nicely as soon as everyone uses the same version of R. Is this really a mandotory prerequisite or is there a possibility to still collaborate using different versions of R?
I could not find any answers on https://rstudio.github.io/renv/index.html...
Any ideas?
You can use different versions of R; however, be aware of issues that can arise (assuming you want everyone to be using the same packages as defined in the renv.lock lockfile):
The packages as declared in the lockfile might not be compatible, or available, for different versions of R;
Packages might behave differently depending on the version of R being used;
The version of R recorded in the lockfile may change depending on the person who is generating the lockfile (via renv::snapshot()).
Ultimately, it may work fine, but if your collaborators run into issues you might want to ask them to ensure they install and use the same version of R as defined in the lockfile.
Related
It is very common for Julia packages to support multiple version of Julia at once. The standard workflow is make modifications in ~/.julia/v0.x/PackageName and then run Pkg.test("PackageName") on the package, but this only tests the package in whatever Julia 0.x is and not other versions. The other versions can't see the local changes since the modifications were only made in 0.x folder. Currently, I rely on Travis on catching problems, but the turn around time is much slower than running tests locally.
What is the proper method for testing a package on multiple versions of Julia locally? Symbolic links?
Use symbolic links.
I've been using symbolic links since julia v0.3. It works reasonably well. I'll typically have the package checked out in the lower version directory, (say 0.4), and have symbolic links in the directories for 0.5 and 0.6. I do this for all packages that I'm actively working on. Everything else get duplicated as part of the Pkg.add/clone process.
This only works of course when you have a single branch of your package (typicaly master) that supports all julia versions, via Compat. In cases where you have different branches for different julia versions, you'll need to have separate checkouts for each julia version.
The development of RStudio and the packages devtools and roxygen2 has made R package creation pretty easy. I use GitHub for version control and devtools allows others to easily install directly from my account.
As my package gradually changes with each version, I'm wondering if I should be maintaining .zip files (or other format) of my past stable builds, in case anyone would ever want to use a previous version.
It's easy to download a .zip of an R package directly from GitHub, but I'm wondering if I should add this to the same GitHub directory (e.g. https://github.com/myaccount/mypackage/previous_versions/mypackage_0.1.zip) without messing up somebody's installation via install_github("myaccount/mypackage").
So, the main Qs are:
Should I keep an old package version at all?
Should I keep old package versions in a sub-folder of my GitHub R package directory?
Should I save .zip files downloaded from GitHub as my old version, or produce a Source or Binary file during the package build itself (i.e. in RStudio)?
Is this a superfluous activity if one isn't yet willing to publish to CRAN?!
When you think your package is at a good solid place, you should tag a release. This archives the branch at that point in time and stores the zip file with the source code, and the tar.gz file.
I tend to mark my CRAN packages as a release each time I release it to CRAN (for example, see https://github.com/nutterb/pixiedust/releases) and with some intemediary tags that I consider noteworthy.
Another good strategy for managing changes in between tagged releases is to maintain a development branch below your main branch. That way your development changes won't pollute or break anything being used by those pulling from your main branch. It makes you free to experiment in the dev branch while always having a clean, working copy to push to and restore from.
1. Should I keep an old package version at all?
It's subjective, but I'd definitely say "yes" unless there's a space constraint, which is probably unlikely.
This serves 2 purposes. One is for your own convenience, such as if you want to make sure that you always have a quick way to test the results of older versions versus a newer version.
The other is that people often need older versions of packages, such as if someone wants to use your package but they're using an older version of R on a server where the policies prevent an update to R. Perhaps a newer version of your package includes a new dependency which only works with a package that depends on a certain version of R or higher.
Of course, packages can always be installed without the compressed or binary files, but it's a nice convenience.
2. Should I keep old package versions in a sub-folder of my GitHub R package directory?
I would put it in a trunk or special subfolder that won't be automatically downloaded when someone tries to install_github or clone your master branch. Having a separate branch is a good idea.
3. Should I save .zip files downloaded from GitHub as my old version, or produce a Source or Binary file during the package build itself (i.e. in RStudio)?
As the package author you're in a position to know if these differ significantly and which if either is better, but by default I'd recommend the RStudio build because I assume (if you're like me) that you're less likely to include unnecessary files this way.
4. Is this a superfluous activity if one isn't yet willing to publish to CRAN?!
No, not necessarily. If people rely on your package then it really doesn't matter if it's on CRAN or not. In fact, not being on CRAN may be a reason to be more proactive like this to ensure that your users will always have access to the needed version of your package.
I use the Revolution R Enterprise distribution that is built upon R 3.2.2. Hence, I have an interest in only employing package versions that are based on this R release as well. Checking packages like 'checkpoint' or the Revolution MRAN page, I only found ways to access snapshots of CRAN datewise. Is there a way to install the most recent package versions still compatible with a certain R release?
I found a heuristical solution to my own problem:
Find out about the release date of the stable R version succeeding your working version.
Set up an R script that calls all the packages you need for your project via individual library() or require() calls.
Use checkpoint(release date minus at least one day) to automatically create a project specific library which is in harmony with your working R version.
Step 2 is a failsafe way to ensure detection of all necessary packages. I called them by sapply(package.list, require), which checkpoint() was not able to handle. A possible caveat against this solution might be that it possibly does not deliver the very last version of a package which is still compatible with your older R version. Alternatively, to be very sure, instead of the stable release one could use the prerelease date to be absolutely sure about compatibility.
I'm trying to write some SPARQL queries in R using the rrdf package. However, I get this error every time I try to load the library.
Error: package 'rrdflibs' 1.1.2 was found, but == 1.1.0 is required by 'rrdf'
Not sure why they didn't write it as >= 1.1.0. Is what they did a good programming practice?
Go to http://cran.r-project.org/src/contrib/Archive/rrdflibs/ to retrieve an older version. This is a source archive, so you will have to be able to build from source (typically easy on Linux, pretty easy on MacOS, and hard on Windows; you can use the http://win-builder.r-project.org/ service to build a Windows binary if necessary).
Actually, based on a quick look at the package, I think you should be able to install in this case (even on Windows without Rtools) via
download.file("http://cran.r-project.org/src/contrib/Archive/rrdflibs/rrdflibs_1.1.0.tar.gz",
dest="rrfdlibs_1.1.0.tar.gz")
install.packages("rrfdlibs_1.1.0.tar.gz",repos=NULL,type="source")
because the package doesn't actually contain anything that needs to be compiled.
Don't know about programming practice, you'd have to ask the authors if they had some particular reason to do it that way. (See maintainer("rrdf").) Maybe they knew the versions would not be backward/forward compatible?
In order to be able to compare two versions of a package, I need to able to choose which version of the package that I load. R's package system is set to by default to overwrite existing packages, so that you always have the latest version. How do I override this behaviour?
My thoughts so far are:
I could get the package sources, edit the descriptions to give different names and build, in effect, two different packages. I'd rather be able to work directly with the binaries though, as it is much less hassle.
I don't necessarily need to have both versions of the packages loaded at the same time (just installed somewhere at the same time). I could perhaps mess about with Sys.getenv('R_HOME') to change the place where R installs the packages, and then .libpaths() to change the place where R looks for them. This seems hacky though, so does anyone have any better ideas?
You could selectively alter the library path. For complete transparency, keep both out of your usual path and then do
library(foo, lib.loc="~/dev/foo/v1") ## loads v1
and
library(foo, lib.loc="~/dev/foo/v2") ## loads v2
The same works for install.packages(), of course. All these commands have a number of arguments, so the hooks you aim for may already be present. So don't look at changing R_HOME, rather look at help(install.packages) (assuming you install from source).
But AFAIK you cannot load the same package twice under the same name.
Many years have passed since the accepted answer which is of course still valid. It might however be worthwhile to mention a few new options that arised in the meanwhile:
Managing multiple versions of packages
For managing multiple versions of packages on a project (directory) level, the packrat tool can be useful: https://rstudio.github.io/packrat/. In short
Packrat enhances your project directory by storing your package dependencies inside it, rather than relying on your personal R library that is shared across all of your other R sessions.
This basically means that each of your projects can have its own "private library", isolated from the user and system libraries. If you are using RStudio, packrat is very neatly integrated and easy to use.
Installing custom package versions
In terms of installing a custom version of a package, there are many ways, perhaps the most convenient may be using the devtools package, example:
devtools::install_version("ggplot2", version = "0.9.1")
Alternatively, as suggested by Richie, there is now a more lightweight package called remotes that is a result of the decomposition of devtools into smaller packages, with very similar usage:
remotes::install_version("ggplot2", version = "0.9.1")
More info on the topic can be found:
https://support.rstudio.com/hc/en-us/articles/219949047-Installing-older-versions-of-packages
I worked with R for a longtime now and it's only today that I thought about this. The idea came from the fact that I started dabbling with Python and the first step I had to make was to manage what they (pythonistas) call "Virtual environments". They even have dedicated tools for this seemingly important task. I informed myself more about this aspect and why they take it so seriously. I finally realized that this is a neat and important way to manage different projects with conflicting dependencies. I wanted to know why R doesn't have this feature and found that actually the concept of "environments" exists in R but not introduced to newbies like in Python. So you need to check the documentation about this and it will solve your issue.
Sorry for rambling but I thought it would help.