[Rd] Auto-upgrading a package under Windows ?

[Dirk Eddelbuettel]

On 20 May 2009 at 13:54, Prof Brian Ripley wrote:
| On Mon, 18 May 2009, Dirk Eddelbuettel wrote:
| 
| >
| > I was trying to be cute with a company-internal package and used
| >
| >    if (Sys.info()["sysname"]=="Windows") {
| >        update.packages(repos="http://some.where.internal/R", ask=FALSE)
| >    }
| 
| The commonly used test is .Platform$OS.type == "windows": that value 
| is computed at installation so will be marginally faster.

Thanks. I once knew about, yet I always forget it. Somehow the Sys.*
connotation wins. 

| > but that of course fails as the package itself is loaded and cannot be
| > upgraded (as it contains a dll) when loaded.  Smart move by the OS.
| 
| It's not only Windows that has that problem, but it does at least 
| report it.  Some Unixen used (at least) to let you replace a DSO which 
| is in use, and then crash the process using the DSO.
| 
| That's an issue with automated updating of R packages in a centrally 
| managed system, so we do it during 'at risk' periods when activity is 
| expected to be low.
| 
| > Can anybody suggest a workaround, other than introducing a dll-free wrapper
| > package that can in fact test for the local packages before it would load
| > them?
| 
| Can you not run a check of up-to-date-ness in the .onLoad hook for the 
| package?  If you load the DLL in that hook, this can be run before the 
| DLL is loaded.  This would need either each package only to update 
| itself or the check to be in all packages that might get updated.

That is exactly what I tried: R/zzz.R using the .onLoad function, before any
actual package code is used.  But (maybe because of the NAMESPACE) this seems
to be after the dll is loaded, and I am in a deadlock.

| You could unload the loaded namespace, provided it has a .onUnload() 
| action that calls library.dynam.unload(), re-install then re-load. 
| However, we've seen instances where unloading and re-loading a DLL in 
| a session did not work (crashes etc) for various reasons -- it does 
| not for example re-load and hence re-initialize any dependendent DLLs.

That never worked for me.

| > Placing the test into Rprofile.site is not a valid answer as that file is
| > hiding on each user's drive and out of my reach.

I will (at least for now) recommend to people to copy the upgrade statement
into their ~/.Rprofile files. 

Thanks, Dirk

-- 
Three out of two people have difficulties with fractions.