Building Packages on Windows using .Rbuildignore (PR#7379)
On Sat, 20 Nov 2004 03:47:50 +0000 (UTC), Gabor Grothendieck
<ggrothendieck@myway.com> wrote:
Duncan Murdoch <murdoch <at> stats.uwo.ca> writes:
On Sat, 20 Nov 2004 00:39:17 +0000 (UTC), Gabor Grothendieck <ggrothendieck <at> myway.com> wrote:
: Even with this change, Rcmd check is still going to install the files : it's supposed to ignore, because it uses Rcmd INSTALL, and there's no : .Rbuildignore support there. : If the behaviour is suddenly changed then this is going to cause work for people whose scripts depend on the current behavior.
Yes, that's normal. If you work around a bug and the bug gets fixed, then you will need to change your code. That's why the NEWS file reports bug fixes and other changes.
In order to minimize disruption I would ask that such change only be made at the same time that a flag for turning on and off .Rbuildignore processing is implemented on build, check, install and build --binary.
There's a simple workaround to turn .Rbuildignore processing off: just rename the file. Adding a switch is *not* a prerequisite for the other changes.
Even with such a flag it may require revision to scripts but at least any change with the flag will be minimal. Even better, it may mean some scripts can be eliminated.
There are 3 changes that I would contemplate: 1. Fix the bug that means "R CMD check" looks in the wrong place for .Rbuildignore. 2. Make "R CMD build --binary" consistent with "R CMD build" in its handling of .Rbuildignore. 3. Make "R CMD install" and "R CMD check" consistent with "R CMD build" in their handling of .Rbuildignore. Number 1 should definitely be fixed in the patches to 2.0.1. I have a feeling that both 2 and 3 should be done (and 2 would be an automatic consequence of 3 unless we took action to stop it), but I'd put them in 2.1.0, not 2.0.x. Martin and you have also suggested 4. Add another flag to Rcmd build (and install and check?), to turn .Rbuildignore processing on and off, for increased flexiblity or for backward compatiblity. My own feeling is that this doesn't increase flexibility enough, and I'd like a better solution, but we've got lots of time before 2.1.0 is released to discuss this.
I did not know it was a bug and even you did not realize it until you looked at the code. I do have one suggestion that might be trivial for you yet be beneficial for everyone else, as an interim step, until a better solution comes about. After fixing the scripts, could you leave the old scripts in bin with new names, e.g. oldbuild, oldcheck, etc. so that one can issue the command: R CMD oldbuild ... and get the old behavior. That provides a simple way to get either behavior while waiting for the ultimate solution and does not interfere with the new scripts in any way.
I think you misunderstand the consequences of fixing the bug. If I fix #1, it should not break any scripts. It will just stop "Rcmd check" from giving a few false alarms about files that you didn't want to distribute anyways. Those files will still be installed in the temporary directory for the checks to run. It is only changes #2 and #3 that would potentially break scripts, which is why I'd save them for 2.1.0. As to the suggestion of leaving both versions of the scripts in place: no, I wouldn't do that. There's nothing to stop you from copying the script from your old version to the new one (or editing the new one to do something completely different, for that matter). But if I were to add three new scripts to the collection, I'd have to document them, and people would have to maintain them. All in all, a big waste of our time to save a little bit of yours? No thanks. Duncan Murdoch