[Rd] particulars of importing/loading libraries
Oleg Sklyar
osklyar at ebi.ac.uk
Wed Jan 14 02:18:31 CET 2009
I will give it a try with .onLoad, but I am not sure why this should be
required. I do not think this is the solution for the problem as at the
times when there were no namespaces, adding a library in Depends of the
Description file was sufficient.
As for the second point I am aware of that, but this just highlights the
problem: pack1 was not made available to the global namespace and
therefore that construction was required.
Best,
Oleg
Paul Gilbert wrote:
> Maybe I'm missing something (it wouldn't be the first time), but I think
> your problem is that pack2 needs a function
>
> .onLoad <- function(library, section) {require("pack1")}
>
> since you actually want the functions from pack1 available, and not just
> its namespace.
>
> ( And you will need the "pack1::" in pack1::testPosixVal only if
> testPosixVal is not exported from pack1. )
>
> Paul
>
> Sklyar, Oleg (London) wrote:
>> I was thinking of this, but this is going to be a pain if a package
>> imports 5 packs, is being imported by another one, which itself is
>> imported by yet another one and the only one one would like to load
>> explicitly is the last down the line. If I do not find a better solution
>> this is what I probably will have to do, reexport everything.
>> Dr Oleg Sklyar
>> Research Technologist
>> AHL / Man Investments Ltd
>> +44 (0)20 7144 3107
>> osklyar at maninvestments.com
>>> -----Original Message-----
>>> From: Martin Morgan [mailto:mtmorgan at fhcrc.org] Sent: 13 January 2009
>>> 16:31
>>> To: Sklyar, Oleg (London)
>>> Cc: r-devel at r-project.org
>>> Subject: Re: [Rd] particulars of importing/loading libraries
>>>
>>> Hi Oleg --
>>>
>>> "Sklyar, Oleg (London)" <osklyar at maninvestments.com> writes:
>>>
>>>> Dear List:
>>>>
>>>> Sorry for posting maybe a trivial question, but I have a basic
>>>> understanding problem. If I have say pack1 and pack2, two R
>>> packages,
>>>> and pack2 depends on and imports pack1 fully (as in the
>>> code below), is
>>>> there a way to make all the functionality of pack1 available for the
>>>> global and other environments (not only for the functions
>>> called from
>>>> withing pack2) by loading pack2 only? I thought if pack2
>>> depends on and
>>>> imports pack1 and essentially reexports everything, one
>>> should get the
>>>> full functionality simply by loading pack2. This does not
>>> seem to be the
>>>> case or I am missing something trivial in my NAMESPACE/DESCRIPTION
>>>> files?
>>> I think that exportPattern does a simple ls() on the environment of
>>> the package name space. The imported symbols are not defined in that
>>> environment, but (I think) in a variable .__NAMESPACE__. and so are
>>> not discovered. Arguably, exportPattern (and friends) should be
>>> smarter. Pragmatically, you need to re-export imported symbols
>>> explicitly. I haven't worked this through entirely, and could be
>>> wrong...
>>>
>>> Martin
>>>
>>>> If this is documented in Writing R Extensions, I would be
>>> thankful for a
>>>> page number and maybe a quick fix in my example below as so
>>> far I have
>>>> not been able to find a clear explanation.
>>>>
>>>> The problem can be illustrated by the following simple
>>> example (this is
>>>> a simple code for 2 packages, pack1 and pack2; plus an example).
>>>>
>>>> Thank you for your replies.
>>>>
>>>> Dr Oleg Sklyar
>>>> Research Technologist
>>>> AHL / Man Investments Ltd
>>>> +44 (0)20 7144 3107
>>>> osklyar at maninvestments.com
>>>>
>>>> --- pack1: DESCRIPTION ------
>>>> Package: pack1
>>>> Version: 0.0.1
>>>> Date: 12 Jan 2009
>>>> Title: pack1 to test S3/S4 methods compatibility
>>>> Author: Oleg Sklyar
>>>> Depends: R (>= 2.7.1), methods
>>>> Maintainer: Oleg Sklyar <osklyar at maninvestments.com>
>>>> Description: pack1
>>>> LazyLoad: yes
>>>> License: Proprietary
>>>> URL: http://www.maninvestments.com
>>>> LazyLoad: no
>>>>
>>>> --- pack1: NAMESPACE ------
>>>> import(methods)
>>>> exportPattern("^[^\\.]")
>>>> exportClasses(posixTime)
>>>> exportMethods(as.POSIXct)
>>>>
>>>> --- pack1: posix.R ------
>>>> setClass("posixTime", "numeric")
>>>>
>>>> setGeneric("as.POSIXct")
>>>> setMethod("as.POSIXct", signature(x="posixTime"),
>>>> function(x, tz) {
>>>> z = x at .Data
>>>> attr(z,"class") = c("POSIXt", "POSIXct")
>>>> attr(z,"tzone") = "UTC"
>>>> z
>>>> }
>>>> )
>>>>
>>>> testPosixVal = new("posixTime", as.numeric(Sys.time()))
>>>>
>>>> --- pack2: DESCRIPTION Package: pack2
>>>> Version: 0.0.1
>>>> Date: 12 Jan 2009
>>>> Title: pack2 to test S3/S4 methods compatibility
>>>> Author: Oleg Sklyar
>>>> Depends: R (>= 2.7.1), methods
>>>> Maintainer: Oleg Sklyar <osklyar at maninvestments.com>
>>>> Description: pack2
>>>> LazyLoad: yes
>>>> License: Proprietary
>>>> URL: http://www.maninvestments.com
>>>> LazyLoad: no
>>>>
>>>> --- pack2: NAMESPACE ------
>>>> import(pack1)
>>>> exportPattern("^[^\\.]")
>>>>
>>>> --- pack2: posix.R ------
>>>> testPosix = function() {
>>>> z = as.POSIXct(testPosixVal)
>>>> print(z)
>>>> print(class(z))
>>>> z
>>>> }
>>>>
>>>> ------ test code to run from global env, showing problems -------
>>>> require(pack2)
>>>>
>>>> ## use as.POSIXct imported into pack2 from pack1 to do the
>>> conversion in
>>>> the fun
>>>> testPosix()
>>>> #~ [1] "2009-01-13 15:29:50 UTC"
>>>> #~ [1] "POSIXt" "POSIXct"
>>>> #~ [1] "2009-01-13 15:29:50 UTC"
>>>>
>>>> ## now try using it directly from the global env (pack1 was not
>>>> explicitly loaded)
>>>> as.POSIXct(pack1::testPosixVal)
>>>> #~ Error in as.POSIXct.default(pack1::testPosixVal) : #~ do not
>>>> know how to convert 'pack1::testPosixVal' to
>>> class "POSIXlt"
>>>> ## now require pack1 explicitly and try again
>>>> require(pack1)
>>>> as.POSIXct(pack1::testPosixVal)
>>>> #~ [1] "2009-01-13 15:29:50 UTC"
>>>>
>>>>
>>>>
>>> **********************************************************************
>>>> Please consider the environment before printing this email
>>> or its attachments.
>>>> The contents of this email are for the named addressees
>>> ...{{dropped:19}}
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> --
>>> Martin Morgan
>>> Computational Biology / Fred Hutchinson Cancer Research Center
>>> 1100 Fairview Ave. N.
>>> PO Box 19024 Seattle, WA 98109
>>>
>>> Location: Arnold Building M2 B169
>>> Phone: (206) 667-2793
>>>
>>
>> **********************************************************************
>> Please consider the environment before printing this email or its
>> attachments.
>> The contents of this email are for the named addressees ...{{dropped:19}}
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> ====================================================================================
>
>
> La version française suit le texte anglais.
>
> ------------------------------------------------------------------------------------
>
>
> This email may contain privileged and/or confidential in...{{dropped:26}}
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466
More information about the R-devel
mailing list