If you’ve tried submitting a package on CRAN, you might have heard of WinBuilder, as it is mentioned in CRAN submission checklist.
In this post inspired by reading R-package-devel archive, we shall go through important questions around WinBuilder.
What is WinBuilder and why use it?
As mentioned in its public-facing web page, WinBuilder ” provides services for building and checking R source packages for Windows.”.
It offers checking on Windows for several R versions.
It is maintained by Uwe Ligges.
What if you already have a machine with Windows locally, or rely on R-hub package builder’s results on Windows?
Well you might still want to use WinBuilder because “it probably has the most recent CRAN checks activated” as written by Duncan Murdoch on R-package-devel.
Checking your package on WinBuilder, though not compulsory, is part of standard advice you’ll be given before a CRAN submission, and of the checklist provided by
How to use WinBuilder?
Among different ways to submit your package to WinBuilder are
Building it from the command line, uploading using ftp, with your favourite tools.
Using the online upload page after building the package.
Running one of
devtools::check_win_release()and friends depending on the R version you’re after.
How to know when WinBuilder is down?
What if you got no result email after more than half an hour?
Maybe WinBuilder is down?
What to do?
You can check the queue for each of WinBuilder’s R version, as explained by Henrik Bengtsson on R-package-devel. E.g. say you submitted your package to the R-release queue: you can simply visit ftp://win-builder.r-project.org/R-release/ in your browser, or use some ftp code, to see if many other packages are stuck in the queue too.
Maybe post on R-package-devel?
What about dependencies on WinBuilder?
WinBuilder’s docs state what system dependencies are available.
“The tools and software provided by Professor Ripley (https://www.stats.ox.ac.uk/pub/Rtools/R215x.html) as well as third party software products mentioned at https://cran.r-project.org/bin/windows/contrib/ThirdPartySoftware.html are available.”
For packages, packages from CRAN, Bioconductor and some packages from OmegaHat are installed by default.
Now, say a package has just been updated on CRAN.
You might have to wait up to two days for its being updated on WinBuilder.
You might ask Uwe Ligges to update it.
You might install it yourself by using serial uploads “Additionally it is possible to install packages serially yourself by uploading them serially: The first package to be uploaded should be the one that is needed by any other packages you upload. Packages you installed yourself are deleted on a regular basis.”
How to deal with WinBuilder’s results
If you got an error/warning/note on WinBuilder that you don’t get locally, you might need to tweak your package and try again.
You could also use
rhub::check_on_windows() if the same error/warning/note appears there too, for a quicker turnaround.
Then you might have to ask for help.
Regarding spell checks, note that there might be false positives.
Can I use WinBuilder for my private package?
WinBuilder is a tool for potential CRAN packages so don’t use it for your private package, especially as the privacy and confidentiality of your uploaded files are not guaranteed.
How to run WinBuilder checks continuously?
WinBuilder is meant to be used as part of your CRAN submission preparation, not as a continuous integration system.
AppVeyor and GitHub Actions have support for Windows.
You could run R-hub checks regularly too.
These different services won’t exactly mimick what WinBuilder does, but will give you useful insight into your package’s behaviour on Windows.
In this post we offered a round-up of information around WinBuilder.
Once you’re happy with the results you got from WinBuilder, and R-hub pre-checks, you’ll submit your package to CRAN and receive incoming checks results.
Once your package gets accepted on CRAN, you’ll deal with other CRAN machines via CRAN checks. 😉