Something that might be of use to you guys is crant (https://github.com/muxspace/crant), which is a set of scripts to make package development and testing simpler. With crant you can build out multiple R instances (release, patch, devel) and then run the build chain against each one. It's compatible with devtools, and we're working on a few other conveniences, like testing all the the reverse depends to understand whether a change to a package breaks downstream dependencies. I've certainly bitten myself and incurred the wrath of CRAN a few times because I didn't check this sort of thing thoroughly enough. Running this on a virtual machine ensures that the environment is clean for building/testing.
Of course, it doesn't address the communication issues (which I find somewhat amusing because the CRAN maintainers always seem to be in absentia during these discussions), but assuming that the CRAN checks are added to the devel branch, it shouldn't matter insomuch as detecting them prior to submission. Understanding the rationale for the change is a different matter. Brian On Sep 15, 2013, at 2:05 PM, Paul Gilbert <pgilbert...@gmail.com> wrote: > On 13-09-14 07:20 PM, Duncan Murdoch wrote: >> On 13-09-14 12:19 PM, Paul Gilbert wrote: >> >> I many not fully understand how much of the response to >>> package submission gets done automatically, but I do get the sense that >>> there is a fairly large amount of actual human time spent dealing with >>> just my submissions alone. If that is representative of all developers, >>> then CRAN maintainers don't have time to do much else. (The fact that >>> they do much more suggests I may not be representative.) >>> >>> Two specific points have already been mentioned implicitly. CRAN >>> submission testing is often done at a higher/newer level using the >>> latest devel version. This results in lots of rejections for things that >>> I would fix before submission, if I knew about them. >> >> Then why don't you test against R-devel before submitting? > > I have been relying on R-forge to provide that testing. One practical > suggestion in this thread (Matthew Dowle) was to test with win-builder > R-devel. This needs to be amplified. I had thought of win-builder as a > mechanism to test on Windows, since I rarely work on that platform. Following > the CRAN submission guidelines I test on win-builder if I am not doing the > Windows testing on my own machine and the R-forge results are not available. > (I think for a single package they are equivalent when R-forge is working.) > But on win-builder I have usually used the R-release directory. Using the > R-devel directory has the advantage that it gives an as-cran test that is > almost up-to-date with the one against which the package is tested when it is > submitted. Another feature of win-builder that I had not recognized is that > submitted packages are available in its library for a short time, so packages > with version dependencies can be tested there, whereas they cannot be tested > on R-forge. >> >> If the tests were >>> rolled out with R, and only later incorporated into CRAN submission >>> testing, I think there would be a lot less work for the CRAN >>> maintainers. >> >> I am an R core member, not a member of CRAN. If I make a change to R, >> I'd like to know the effect it has on the corpus of CRAN and >> Bioconductor packages, but I don't have the computing resources to run >> it against all of those in a reasonable amount of time. We have heard >> from various corporate users of R (Revolution Computing and Google are >> two) that they would like to contribute to the project, but we don't >> actually see useful contributions from them. >> >> I don't know if you personally have influence with anyone who has such >> resources, > > As far as I know I don't have any influence with anybody, but I like this > suggestion. > > Paul > >> but surely some on this list do. So why don't they write to >> me and tell me how to use their computing resources to run proposed >> changes against all published packages? I think it's because it's >> easier to do nothing than to do something. It's certainly easier to say >> that it's the CRAN maintainers' fault for poor communication than it is >> to identify and address the problems. >> >> Duncan Murdoch >> >> >> (This is ignoring the possibility that CRAN submission is >>> really the testing ground for the tests, and to prove the tests requires >>> a fair amount of manual involvement. I'm happy to continue contributing >>> to this -- I've often felt my many contribution is an endless supply of >>> bugs for the checkers to catch.) >>> >>> The second point is that a facility like R-forge that runs the latest >>> checks, on many platforms, is really useful in order to reduce work for >>> both package developers and CRAN maintainers. With R-forge broken, the >>> implication for additional work for CRAN maintainers seems enormous. But >>> even with it working, not all packages are kept on R-forge, and with >>> package version dependencies R-forge does not really work. (i.e. I have >>> to get new versions of some packages onto CRAN before the new versions >>> of other packages will build on R-forge.) Perhaps the package checking >>> part of R-forge should be separated into a pre-submission clearing house >>> to which packages are submitted. If they pass checks there then the >>> package developer could click on a submit button to do the actual >>> submission to CRAN. (Of course there needs to be a mechanism to plead >>> for the fact that the test systems do not have needed resources.) >>> Something like the daily, but with new pre-release versions of packages >>> might actually be better than the R-forge approach, for two reasons. One >>> is that package maintainers would only put packages there that they >>> think are actually working. (R-forge tries to build my svn copy even >>> when I know it is broken.) The second is that it would automatically >>> handle the version dependency problem, since package maintainers would >>> have the ability to put in place versions that should work together. >>> However, this does not need to be run daily. It only needs to be run >>> when the checks change, or for a package when the package changes. >>> >>> Paul >>> >>>> >>>> Duncan Murdoch >>>> ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
