--- On Thu, 30/7/09, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
> >>>>> "HL" == Hin-Tak > Leung <hintak_le...@yahoo.co.uk> > >>>>> on Thu, 30 Jul > 2009 08:59:01 +0000 (GMT) writes: > > HL> --- On Thu, 30/7/09, Martin Maechler > <maech...@stat.math.ethz.ch> > wrote: > >> I'm not sure this addresses all the > problems that your > >> patch > >> tried to fix, > >> but in any case, your patch > re-installing the --vanilla > >> behavior > >> unconditionally (without the > .libPaths()[1] detection) was > >> not > >> suffificient. > > HL> But I think .libPaths should not be > _implicitly_ user-/site- overridded - afterall, non-standard > locations are already catered for with the -l option (which > presumbably does the same thing as declaring R_LIBS, just > explicitly). > > We are talking *only* about the case where no '-l' (or > 'lib.loc') was specified, and the default has always been > to > take the first entry in .libPaths() .... [ with all > its > problems when that is not writable, but that's a different > story] > > > HL> This is analogous to installing system > libraries and run-time relocation - while people do install > binaries and libraries in non-standard locations and > customize their $PATH and $LD_LIBRARY_PATH to reflect that > either at the user- or site- level, it would be quite > strange to allow ./configure or other equivalent software > building tools to peek at the first part of PATH or > LD_LIBRARY_PATH and put executables in the former and > libraries in the latter... That's almost anarchy :-). > > The comparison is interesting, and slightly off I think: > Again, we are only talking about the case when there's > *no* > default library location specified for package > *installation*. > > HOWEVER, > the case I mentioned, where I have scenarios where I was > able to > use > 'R_LIBS=...:...:.... R CMD check > <mypkg>' > > using non-default library locations, not for installation > (because that would be <mypkg>.Rcheck > anyway), but for > searching of package *dependencies* of <mypkg> > is also something that has stopped working in the current > R-devel, because it uses our site-wide Rprofile and that > sets > R_LIBS differently itself. > > -- > > Anyway, I think it would not be a bad course to still > *allow* > "vanilla-INSTALL" but keep the current R-devel > default > behavior. > But maybe we can find something better. > (and hopefully other R core members will explain more > clearly > why they think it was "the correct" default behavior to > obey > site-wide and user-specific Rprofile > settings) But there is always a shipped default? $R_HOME/library , and I seem to recall for non-admin users, $HOME/R/<arch> . .libPath() is $R_HOME/library on R --vanilla . If the user or site admin choose a configuration to prepend .libPath() with a customization via Rprofile/R_LIBS, it stands to reason that he/she should also do -l for installation? (or rather, it should happen the other way round - if one choose to install, *consciously*, elsewhere than the default, than Rprofile/R_LIBS is required) Nonetheless, I think we are drifting a little. the original problem was that it is not possible to upgrade/overwrite a package and its associated resources like its namespace when that package is loaded. Maybe the correct solution is to unload the said package, unregister the dlls/shared-libraries, and unload a namespace on installation. I seem to recall that there are some issues about dll unloading on windows, but that's a technicality... ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
