When in Doubt, Upgrade

I have said this many times in several Github issues and it is also the very first FAQ of knitr. It is a little exaggerative and certainly not a universal rule, but it helps a lot if you could try to upgrade everything before you report a software issue. It is even more helpful if you could also install the development version of the software and see if the problem has gone. Although it sounds like a joke, @ThePracticalDev actually has a very good point:

You may replace “Changing Stuff” with “Upgrading Stuff” above.

A few notes from my personal experience just for your reference and also for my future self (not meant to be a guide):

• R and R packages: Unless you are a developer who cares a lot about different versions of R and has to install multiple versions of R,¹ do not use or configure a versioned library path for R packages. For example, when you set R_LIBS_USER in ~/.Renviron, do not include the version number %V or %v. See more info on the help page ?R_LIBS. This means all versions of R will use the same library path, e.g., R_LIBS_USER=~/R. This can cause you (serious) problems after you upgrade R because some old R packages can be broken (e.g. from R 3.3.x to 3.4.0), but don’t worry, the solution is simple:

  update.packages(ask = FALSE, checkBuilt = TRUE)
  

  I always recommend checkBuilt = TRUE. It is a conservative choice, which may waste you a few more minutes to reinstall packages that actually still work well under the new version of R, but I prefer safty over time.

• Homebrew: brew upgrade && brew cleanup. Homebrew is one of the two most important reasons why I switched from Linux to macOS a few years ago.² It is so awesome and convenient, and is exactly how I expect how system package manager to work: allow the community to help manage packages via Github pull requests. I’m seriously looking forward to Jeroen’s project on building R packages with Homebrew. This is something I have waited for long, and I think the future of Homebrew R is brighter than the CRAN binaries of R and R packages.

• LaTeX: I think everybody knows that I dislike everything about LaTeX except the PDF output.³ I dislike the installation, maintainence, syntax, and debugging process of LaTeX. Almost everything is painful on every platform.⁴ I’m not going to rant more, but just point out that updating LaTeX (and LaTeX packages) could be trickier than you imagined.

  • For Linux users, I recommend installing TeXLive from source and either add the bin path to PATH or sudo tlmgr path add. Then you can enjoy (or suffer from) tlmgr instead of waiting for years for the official repo to have a recent version of TeXLive. For macOS users, MacTeX seems to be fine. When in doubt, tlmgr update --self --all (requires sudo on macOS). Still in doubt? Run fmtutil-sys --all, whatever it means (again, may require sudo, depending on where you installed LaTeX).

  • For Windows users, updating MikTeX may require you to update both LaTeX packages and refresh the filename database (whatever it means). Go to the Start menu, find MikTeX, and click any buttons that sound like “update me” (clicking buttons and seeing what happens).

Personally I prefer using the latest versions of software packages, and I upgrade whenever possible (kind of obsessive), because I don’t want to run into old bugs that have been fixed. This is not necessarily a good choice or the right thing to do, and I don’t have evidence about whether newer or older versions are better or worse in general. Newer versions may have new bugs or changes that you hate. All I want to express in this post is that when you are in trouble, you may try to upgrade first.