Duncan Murdoch <murdoch <at> stats.uwo.ca> writes: : : On Sat, 20 Nov 2004 03:47:50 +0000 (UTC), Gabor Grothendieck : <ggrothendieck <at> 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.
Perhaps I used the wrong words. I do checks with and without .Rbuildignore processing so having both facilities is convenient. : : It is only changes #2 and #3 that would potentially break scripts, : which is why I'd save them for 2.1.0. I agree that that two stage approach would reduce the extent of the problem of change in behavior. : : 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. You don't need to document deprecated code. Its just there for the convenience of the user base that has invested in it. ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
