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

From: Gabor Grothendieck <ggrothendieck_at_myway.com>
Date: Sat 20 Nov 2004 - 16:22:21 EST

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.



R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Sat Nov 20 16:29:54 2004

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:01:38 EST