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:[EMAIL PROTECTED]
>>>Enviado el: jue 22/06/2006 15:47
>>>Para: Iago Mosqueira
>>>CC: r-devel@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)
>>>
>>>[EMAIL PROTECTED]
>>>http://www.azti.es/
>>>
>>>
>>>
>>
>>------------------------------------------------------------------------
>>
>>>______________________________________________
>>>R-devel@r-project.org mailing list
>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
