[Rd] NAMESPACE and bundle

Philippe Grosjean phgrosjean at sciviews.org
Thu Jun 29 13:25:33 CEST 2006


Iago Mosqueira wrote:
> El jue, 22-06-2006 a las 10:37 -0400, Paul Gilbert escribió:
> 
>>Iago
>>
>>I think your R code file  needs an .onLoad function.  Here is the 
>>..onLoad from my dse1 package which is in the dse bundle, as is tframe,  
>>along with comments which I had forgotten.
>>
>>..onLoad  <- function(library, section) {
>>   .DSEflags(list(COMPILED=TRUE, DUP=TRUE))
>>   # next require is necessary for bundle check to run examples, 
>>   # but does not seem to be necessary when packages are not bundled
>>   require("tframe")
>>   invisible(TRUE)
>>   }
>>
>>
>>Hope this works,
>>Paul
> 
> 
> Hi,
> 
> Thanks for the tip. I already had an .onLoad() function, with 
> 
> .onLoad <- function(lib,pkg) {
> 	require(methods)
>         require(FLCore)
> }
> 
> the first to comply with the needs of an S4 package, the second to solve
> the internal dependency that outside of the bundle is solved with
> Depends: in DESCRIPTION.

Hello Iago,

In principle, you should not use require() statements any more. 
Dependences should be resolved in the NAMESPACE and in Depends: field of 
description. It works for me for the SciViews bundle. I think that the 
situation is the same as for FLR: I have a svMisc package with basic 
functions, and all other packages depend on it, plus other complex 
interdependences between the other packages in the bundle.

You should really think twice before distributing a bundle: it is more 
of a problem. First, you force users to download and install the whole 
bundle (by definition!), even if they are interested by ony a part of 
it. Second, it is the same for updates: if you change something in one 
package, you must upload the whole bundle.

Now that dependencies are nicely resolved during R package installation, 
  bundles are not so attracting, and I would advise to continue 
distributing your packages separately.

Best,

Philippe Grosjean

> Is there anything else I could look at?
> 
> Thanks,
> 
> 
> Iago
> 
> 
> 
> Iago Mosqueira wrote:
> 
> 
>>>-----Mensaje original-----
>>>De: Paul Gilbert [mailto:pgilbert at bank-banque-canada.ca]
>>>Enviado el: jue 22/06/2006 15:47
>>>Para: Iago Mosqueira
>>>CC: r-devel at r-project.org
>>>Asunto: Re: [Rd] NAMESPACE and bundle
>>
>>>Iago
>>
>>>There is a problem that bundle checking works slightly differently
> 
> than
> 
>>>individual package checking in this regard.  I think it has to do
> 
> with
> 
>>>when the namespace gets registered, or something like that. As I
> 
> recall,
> 
>>>the work around is to explicitely require  the package in the test
> 
> files
> 
>>>for it. I.e. put
>>>  require("pac")
>>>in all the files in pac/tests.   If that does not work, let me know
> 
> and
> 
>>>I will look more carefully to find what I had to do.
>>
>>>Paul
>>
>>
>>Paul,
>>
>>Many thanks. The problem is in the examples contained in the Rd
> 
> files, 
> 
>>where we do not explictely load the package, as we do in test files. 
>>But it is only a problem for the examples in this package, not in the 
>>others that share the same package dependencies. Can you see any 
>>solution or something I else I should check for?
>>
>>Thanks
>>
>>
>>Iago
>>
>>
>>Iago Mosqueira wrote:
>>
>>
>>>Dear all,
>>>
>>>I have a package that passes R CMD check, and shows no problems when 
>>
>>using all its methods as declared in NAMESPACE. When this package is 
>>added to a bundle, which already consists of 5 packages, the examples 
>>in the Rd pages thta call a number of methods fail during the bundle 
>>check. These all passed when check is run on this package alone.
> 
> Other 
> 
>>packages in the bundle are very similar, in that all import all S4 
>>classes and methods from the first package (using import("FLCore") in 
>>NAMESPACE) in the bundle, and export their own overloaded methods.
>>
>>>If I run check on a mini-bundle consisting only of the main package 
>>
>>(FLCore) and this problematic package, it shows no problem. So I 
>>assume a problem of NAMESPACE conflict is the culprit, but 
>>experimnting with various package combinations, to try and isolate
> 
> the 
> 
>>conflict, has not worked. This package seems to conflict with every 
>>other secondary package.
>>
>>>I am dealing with internal dependencies by adding a require(FLCore) 
>>
>>line to the .onLoad() call in zzz.R
>>
>>>Can anybody point me at what to look for? What could be the reason 
>>
>>for this problem?
>>
>>>I hope the explanation was clear enough. Many thanks,
>>>
>>>
>>>Iago
>>>
>>>
>>>Dr. Iago Mosqueira
>>>
>>>Marine Research Division
>>>AZTI Tecnalia
>>>Txatxarramendi Ugartea, z/g
>>>48395 Sukarrieta - Bizkaia
>>>Spain
>>>
>>>+34 946 029 448
>>>+34 946 029 400
>>>+34 946 029 401 (Fax)
>>>
>>>imosqueira at suk.azti.es
>>>http://www.azti.es/
>>>
>>>
>>>
>>
>>------------------------------------------------------------------------
>>
>>>______________________________________________
>>>R-devel at r-project.org mailing list
>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
> 
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list