R devel - Dec 2004 - More on Lazy loading errors building its package in a chroot

From:   Dirk Eddelbuettel <edd@debian.org>
> I now have the package built in a chroot -- but at the price of setting
> 'LazyLoad: no' in DESCRIPTION. 
> 
> I do not quite understand why that is needed. Can someone else help? I can
> provide the following pointers for its-1.0.4
> 
I have had problems on Windows in which I had to pay the
same price and it turned out that by using forward slashes
rather than backslashes in pathnames my R CMD ...  line I
circumvented it.  Now this obviously is not your problem but
it shows that such a workaround can represent unexpected
causes.
> * The file 'DESCRIPTION' has the Depends on methods, stats and
Hmisc. Under
> Debian Hmisc and acepack get properly loaded as needed to build this.
> 
> * A file 'install.R' still exists from the older version. I reckon
it can
> be removed, but it doesn't seem to matter either way.
> 
> * The file 'NAMESPACE' is there, it contains import(), export(),
> exportClass() and exportMetods() directives.
> 
> * The file R/itspkg.r has 
> .onLoad <- function(lib, pkg) require(methods)
> [...]
> as.its.zoo <- function(x) {
> stopifnot(require(its))
> index <- attr(x, "index")
> stopifnot(inherits(index, "POSIXct"))
> attr(x, "index") <- NULL
> its(unclass(x), index)
> }
The as.its.zoo function was originally part of the 'zoo'
package.   It was moved to 'its' since it seemed to make
more sense there.  The 'require(its)' line was needed when it
was part of 'zoo' but now that it is part of 'its' I think
it can be eliminated.  Check if that has any effect.
> and I have the feeling that these may interfere with the LazyLoad
> directive. But I just don't understand how something can work in 
> session with a controlling terminal, but fail in the chroot'ed batch
> built. 
> 
> Comments would be highly welcome. But please speak very slowly when it
comes
> to S4 and LazyLoading matters. 
There is an article on Lazy Loading in R News you may wish
to read.
> 
> Thanks, Dirk
> 
> 
> 
> On Tue, Dec 14, 2004 at 10:17:16PM -0600, Dirk Eddelbuettel wrote:
> > Trying to build its_1.0.4 in a chroot environment to update the
> > corresponding Debian package, I get 
> > 
> > 
> > * Installing *source* package 'its' ...
> > ** R
> > ** inst
> > ** save image
> > Loading required package: Hmisc
> > Hmisc library by Frank E Harrell Jr
> > 
> > Type library(help='Hmisc'), ?Overview, or
?Hmisc.Overview')
> > to see overall documentation.
> > 
> > NOTE:Hmisc no longer redefines [.factor to drop unused levels when
> > subsetting. To get the old behavior of Hmisc type dropUnusedLevels().
> > 
> > Attaching package 'Hmisc':
> > 
> > 
> > The following object(s) are masked from package:stats :
> > 
> > ecdf
> >            
> > Creating a new generic function for "names" in
"its"
> > Creating a new generic function for "names<-" in
"its"
> > Creating a new generic function for "print" in
"its"
> > Creating a new generic function for "start" in
"its"
> > Creating a new generic function for "end" in "its"
> > Creating a new generic function for "summary" in
"its"
> > Creating a new generic function for "diff" in
"its"
> > Creating a new generic function for "union" in
"its"
> > Creating a new generic function for "intersect" in
"its"
> > 
> > ** preparing package for lazy loading
> > Error in loadNamespace(name) : There is no package called
'its'
> > Execution halted
> > ERROR: lazy loading failed for package 'its'
> > make: *** [R_any_arch] Error 1
> > pbuilder: Failed autobuilding of package
> >            
> > 
> > The package installs fine when built on the command-line. This is
somehow
> > related to the reduced environment provided in the chroot -- I recall
having
> > seen (and fixed) the error when other packages where needed during
build
> > time. Hmisc is installed. Nothing else outside of R-base should be
needed.
> > 
> > I think I am overlooking something simple, but a couple of simple
attempts
> > didn't get me anywhere. The chroot isn't a problem per se as
several dozen
> > CRAN packages get built that way into Debian packages.
> > 
> > Puzzled, Dirk
>

On Sat, Dec 18, 2004 at 02:10:10PM -0500, Gabor Grothendieck
wrote:
> > I now have the package built in a chroot -- but at the price of
setting
> > 'LazyLoad: no' in DESCRIPTION. 
> > 
> > I do not quite understand why that is needed. Can someone else help? I
can
> > provide the following pointers for its-1.0.4
> > 
> 
> I have had problems on Windows in which I had to pay the
> same price and it turned out that by using forward slashes
> rather than backslashes in pathnames my R CMD ...  line I
> circumvented it.  Now this obviously is not your problem but
> it shows that such a workaround can represent unexpected
> causes.
Indeed.
> > * The file 'DESCRIPTION' has the Depends on methods, stats and
Hmisc. Under
> > Debian Hmisc and acepack get properly loaded as needed to build this.
> > 
> > * A file 'install.R' still exists from the older version. I
reckon it can
> > be removed, but it doesn't seem to matter either way.
> > 
> > * The file 'NAMESPACE' is there, it contains import(),
export(),
> > exportClass() and exportMetods() directives.
> > 
> > * The file R/itspkg.r has 
> > .onLoad <- function(lib, pkg) require(methods)
> > [...]
> > as.its.zoo <- function(x) {
> > stopifnot(require(its))
> > index <- attr(x, "index")
> > stopifnot(inherits(index, "POSIXct"))
> > attr(x, "index") <- NULL
> > its(unclass(x), index)
> > }
> 
> The as.its.zoo function was originally part of the 'zoo'
> package.   It was moved to 'its' since it seemed to make
> more sense there.  The 'require(its)' line was needed when it
> was part of 'zoo' but now that it is part of 'its' I think
> it can be eliminated.  Check if that has any effect.
I had commented that out earlier in the week during my first attempts at
building the package.
> 
> > and I have the feeling that these may interfere with the LazyLoad
> > directive. But I just don't understand how something can work in 
> > session with a controlling terminal, but fail in the chroot'ed
batch
> > built. 
> > 
> > Comments would be highly welcome. But please speak very slowly when it
comes
> > to S4 and LazyLoading matters. 
> 
> There is an article on Lazy Loading in R News you may wish
> to read.
Yes, I have planned to reread it.

Thanks for the feedback.

Dirk

-- 
If you don't go with R now, you will someday.
  -- David Kane on r-sig-finance, 30 Nov 2004