From ripley at stats.ox.ac.uk  Thu May 21 08:11:10 2009
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Thu, 21 May 2009 07:11:10 +0100 (BST)
Subject: [Rd] Auto-upgrading a package under Windows ?
In-Reply-To: <18964.43362.572242.261641@ron.nulle.part>
References: <18961.48417.945981.635658@ron.nulle.part>
	<alpine.LFD.2.00.0905190808200.24633@gannet.stats.ox.ac.uk>
	<18964.43362.572242.261641@ron.nulle.part>
Message-ID: <alpine.LFD.2.00.0905210709460.30721@gannet.stats.ox.ac.uk>

On Wed, 20 May 2009, Dirk Eddelbuettel wrote:

>
> 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 would need not to use UseDynLib in the NAMESPACE, but load the DLL 
in the .onLoad via library.dynam.

> | 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.
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595



[Rd] Auto-upgrading a package under Windows ?
Prof Brian Ripley