R help - Apr 2008 - loading an updated version of a package during an active R session?

I am developing a package and I want to be able to load an updated 
version of the package from within an active R session.  Suppose, for 
example, I have a function f within a package X.  In my active R 
session, I have already loaded X.  Then I change the R source code of f 
within X and rebuild the package as a .tar.gz file on the command line with

   R CMD build X

Within my R session, is there a way to reload X such that the updated 
definition of f will be used?  I have tried:

   > detach("package:X")
   > install.packages("X.tar.gz", repos=NULL,
type="source")
   > library(X)

but this seems to use the old version of f.  Any suggestions would be 
much appreciated!

Many thanks in advance!

Roger

On Wed, 9 Apr 2008, Roger Levy wrote:
> I am developing a package and I want to be able to load an updated
> version of the package from within an active R session.  Suppose, for
> example, I have a function f within a package X.  In my active R
> session, I have already loaded X.  Then I change the R source code of f
> within X and rebuild the package as a .tar.gz file on the command line with
>
>   R CMD build X
>
> Within my R session, is there a way to reload X such that the updated
> definition of f will be used?  I have tried:
>
>   > detach("package:X")
>   > install.packages("X.tar.gz", repos=NULL,
type="source")
>   > library(X)
>
> but this seems to use the old version of f.  Any suggestions would be
> much appreciated!
It does work for some packages but not in general.  If the package has 
a namespace, you need to unload that, e.g.

unloadNamespace("X")

before library(X) (and that will detach X as well).  Note too that many 
(most?) packages with DLLs do not unload the DLL when their namespace is 
unloaded (or they are detached), in which case you can end up with the new 
R code and the old compiled code.

So without more details or the example asked for in the footer it is hard 
to be explicit about what needs to be done.
> Many thanks in advance!
>
> Roger
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
-- 
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

Prof Brian Ripley wrote:
> On Wed, 9 Apr 2008, Roger Levy wrote:
> 
>> I am developing a package and I want to be able to load an updated 
>> version of the package from within an active R session.  Suppose,
>> for example, I have a function f within a package X.  In my active
>> R session, I have already loaded X.  Then I change the R source
>> code of f within X and rebuild the package as a .tar.gz file on the
>> command line with
>> 
>> R CMD build X
>> 
>> Within my R session, is there a way to reload X such that the
>> updated definition of f will be used?  I have tried:
>> 
>>> detach("package:X")
install.packages("X.tar.gz", repos=NULL,
>>> type="source") library(X)
>> 
>> but this seems to use the old version of f.  Any suggestions would
>> be much appreciated!
> 
> It does work for some packages but not in general.  If the package
> has a namespace, you need to unload that, e.g.
> 
> unloadNamespace("X")
> 
> before library(X) (and that will detach X as well).
Ah, I see -- I was under the mistaken impression that detaching the
package would also get rid of the namespace.  In my particular case,
using unloadNamespace() did the trick properly.
> Note too that many (most?) packages with DLLs do not unload the DLL
> when their namespace is unloaded (or they are detached), in which
> case you can end up with the new R code and the old compiled code
In my case I am developing on OS X so there are no DLLs, but this is a
good proviso to know.  Does the same proviso apply to shared objects in 
Unix and OS X?

Best & many thanks.

Roger
> So without more details or the example asked for in the footer it is
> hard to be explicit about what needs to be done.

-- 

Roger Levy                      Email: rlevy at ucsd.edu
Assistant Professor             Phone: 858-534-7219
Department of Linguistics       Fax:   858-534-4789
UC San Diego                    Web:   http://ling.ucsd.edu/~rlevy