Currently, I am teaching a new course Empirical Economics with R. The RTutor problem set for the chapter on Difference-in-Difference estimation uses the great package lfe. I consider it an essential package to convince Stata users (still most empirical economists) to move to R, because it allows to combine with a single function call fast fixed effects estimation, use of instrumental variables and cluster-robust standard errors.

However, yesterday a student send me an email that he could not install the lfe package because it was no longer on CRAN. The CRAN page looked as follows:

While there is a link to an archive, it only contains source versions of the package. The lfe package has C code, i.e. installing from source would e.g under Windows require to install RTools. However, I really would prefer not having to ensure that all my (non-computer science) students with diverse OS have the proper toolchain to compile such packages from source.

The short-term rescue: Microsoft’s CRAN snapshots

First, I came up with the more complicated solution to create binary versions for different OS using r-hub and then host those binary lfe packages on my own drat-powered and R repository on Github.

Yet, then I found a much simpler solution: the daily Microsoft’s CRAN snapshots. Here is the archived CRAN page from 2020-12-04 when lfe was still on CRAN. We can install that version by simply running:

install.packages("lfe",repos=unique(c(
    getOption("repos"),
    repos="https://cran.microsoft.com/snapshot/2020-12-04/"
)))

This code first checks the default CRAN repository (should lfe reappear) and otherwise uses Microsoft’s snapshot.

What if there is a new major R version?

It might be that Microsoft’s CRAN snapshots work nicely only until the day there is a new major R version, because new major R versions tend to require newly compiled binaries. If one wants to use the package for a course afterwards, one may have to restort to host an own drat-powered repository using r-hub to create the appropriate binaries for different OS. (Hint: If you use the r-hub web interface, you have to click on the artifacts link in the email from r-hub after a successful build to access the created binaries.)

A hope for the future: A less stringent CRAN alternative

If one looks at the CRAN check results for the lfe package from 2020-12-04, my interpretation (possibly wrong) is that the only problem seem to have been a note (not a warning or error) only for the compilation on Solaris:

There are probably different opinions, but it seems to me a very tough decision to remove an extremely useful package from CRAN just because there was such a note for Solaris.

Do we really have to force statisticians who write very useful packages to dig deeply into compiler intricacies for a operating system probably most users never have heard about, just to remove a note?

And must all package users suffer if such a note cannot be removed (for whatever reason, e.g. time constraints of the package maintainer)?

Of course, the CRAN maintainers really do a lot of great work for the community and spend immense time ressources. So, of course, it is their right to specify the CRAN guidelines as they want and in a way that makes CRAN still manageable.

Still, personally, I would love if either CRAN would become less stringent or some organisation (RStudio perhaps?) would some day support an alternative repository with less stringent standards and more concerns about the trouble generated for users when removing a package just because of a compiler note for Solaris.

Until then let’s hope such issues get quickly resolved so that such important packages find their way back to CRAN.