[Rd] Building Packages on Windows using .Rbuildignore (PR#7379)

[Gabor Grothendieck]

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.