R 2.8->2.9 change that breaks some upgrade scenarios

"HL" == Hin-Tak Leung <htl10 at users.sourceforge.net>
    on Mon, 6 Jul 2009 15:23:07 -0700 (PDT) writes:

HL> I finally got round to look at a little problem I have - most of the time when I use R I would be using snpMatrix (now part of bioconductor, I wrote a substantial part of), so I had $HOME/.Rprofile to save some typing. Upgrading, switching versions used to work fine with R 2.8 then it broke with 2.9..

    HL> Apparently it is because most of SHLIB, INSTALL, etc used to be fairly extensive shell scripts in R 2.8 where options not specific to a particular script is passed to R itself. Those scripts also do more of --vanilla (--no-site-files, --no-init-files, etc), and it is also possible to pass --vanilla, etc explicitly. The R 2.9 implementations of these scripts are fairly thin wrappers of R routines, and they silently(?) ignore extra options.

    HL> The specific behaviors of the scripts are probably not gauranteed, and it is no problem temporarily moving .Rprofile away, etc for the occasional installations/upgrade of packages, but I think it is a valid scenario to want to have a site-/user-customized profile for day-to-day R usage, and a clean/vanilla R session for installation, etc. A few more of the 
    HL> --no-site-files, --no-init-files, options should go into the R 2.9 versions of SHLIB, INSTALL, etc?

R 2.9.x  uses  R code instead of the previous perl code for 
INSTALL. That's the explanation for the difference.

I agree that it would be quite useful if they supported features
as you mention, and we (R-core) will be very willing to accept
(well-tested) patches enabling that.

Regards,
Martin Maechler, ETH Zurich

"HL" == Hin-Tak Leung <htl10 at users.sourceforge.net>
    on Mon, 6 Jul 2009 15:23:07 -0700 (PDT) writes:

    HL> I finally got round to look at a
little problem I have - most of the time when I use R I
would be using snpMatrix (now part of bioconductor, I wrote
a substantial part of), so I had $HOME/.Rprofile to save
some typing. Upgrading, switching versions used to work fine
with R 2.8 then it broke with 2.9..

    HL> Apparently it is because most of
SHLIB, INSTALL, etc used to be fairly extensive shell
scripts in R 2.8 where options not specific to a particular
script is passed to R itself. Those scripts also do more of
--vanilla (--no-site-files, --no-init-files, etc), and it is
also possible to pass --vanilla, etc explicitly. The R 2.9
implementations of these scripts are fairly thin wrappers of
R routines, and they silently(?) ignore extra options.

    HL> The specific behaviors of the scripts
are probably not gauranteed, and it is no problem
temporarily moving .Rprofile away, etc for the occasional
installations/upgrade of packages, but I think it is a valid
scenario to want to have a site-/user-customized profile for
day-to-day R usage, and a clean/vanilla R session for
installation, etc. A few more of the 
    HL> --no-site-files, --no-init-files,
options should go into the R 2.9 versions of SHLIB, INSTALL,
etc?

R 2.9.x  uses  R code instead of the previous perl code for 
INSTALL. That's the explanation for the difference.

I agree that it would be quite useful if they supported
features as you mention, and we (R-core) will be very willing to
accept (well-tested) patches enabling that.

I had a bit more thoughts on this issue since - the R 2.8 behavior (disabling user/site customization) during package installation is probably more sensible; I don't know of any user/site customization that are useful/necessary during installation. Adding --vanilla to SHLIB, INSTALL is fairly trivial? (unfortunately, with R 2.9 one can no longer do 'R --vanilla CMD INSTALL ...' for reasons I already explained, as the --vanilla option in R 2.9 needs to go inside of the INSTALL script to have any effect). I can submit a patch fairly easily, but I guess the question is, is there any scenario where one *wants* site/user customization active during package installation?

Unfortunately with the R 2.9 implementation of those scripts, it is all or nothing. (all command line arguments are passed to R routines inside R for processing; there is no mechanism to modify how R is started in the new R 2..9 scripts. Well, with some extensive/painful change it is possible, but then it is basically and conceptually reverting back to the R 2.8 way with an extensive shell script wrapper).

R 2.9.x? uses? R code instead of the previous perl code for 
INSTALL. That's the explanation for the difference.

I agree that it would be quite useful if they supported features
as you mention, and we (R-core) will be very willing to accept
(well-tested) patches enabling that.

I just checked R trunk - only "SHLIB", "INSTALL", "REMOVE" has undergone the shell/perl script->R routine transformation. I would suggest just adding --vanilla to those three. (personally I have never used the last one - just dumping the package directory from within the library directory normally remove almost all trace of a package anyway).

Hin-Tak