[Rd] r-forge build failure bafflement

Fri Mar 30 23:12:34 CEST 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

  Figured it out (I think: I haven't gotten through restructuring and
testing, but I think it's going to work now).  I was paying
insufficient attention to the build arguments, in particular
- --resave-data=best.

  I previously had the clever idea to save some fitted models with the
package so that they would be available to users who wanted to work
with them without taking the time and trouble of re-running the model
fits (some of which are very slow, especially for MCMC variants).  So
I saved these in a .rda file in the data section, which seemed like a
good idea at the time.  However, that means that resaving the data now
requires loading the package with which the class of those model
objects is associated ... and voila, a mysterious, apparently
self-referential, error message.

   For now I'm experimenting with moving those fits to a .rda file
inst/extdata ... (I thought using to dput() instead of save() to save
them might fix the problem, but it doesn't seem to) but this does seem
like a bit of a pain (I have included anther function, getdata(), so
that users don't have to mess around with system.file("extdata",
[model_obj], package="glmmADMB"). I would be curious if anyone has any
other suggestions for ways to work around this issue, or if they feel
that I am subverting the intended use of the data/ directory (and so
it's my own fault).

  happy friday, and thanks to all for their suggestions.

    Ben Bolker

On 12-03-30 01:38 AM, Prof Brian Ripley wrote:
> We've seen similar things several times with CRAN submissions.
> Basic scenario was
> 
> - INSTALL (via build or check) is trying to install a package that
> is not already installed, into a private library not on the usual
> .libPaths().
> 
> - Start-up code in that package is looking for the package, and
> does not respect lib[name] as passed to .First.lib or
> .onLoad/.onAttach.  E.g. a call to installed.package() or
> packageDescription.
> 
> - As the maintainer has an earlier version installed in .Library
> (s)he cannot reproduce it.
> 
> I took a very quick look at the package: it has .First.lib and not 
> .onLoad/.onAttach, and of course it has a namespace (all packages
> now do).  I would start by fixing that.
> 
> On 29/03/2012 21:54, Ben Bolker wrote:
>> 
>> I am attempting to build a package on r-forge and running into a 
>> weird error.  I have been in correspondence with the R-forge
>> admins and am turning to r-devel on the remote chance that
>> someone might have a guess as to what is going wrong or a
>> suggestion about further diagnostics/experiments I could try ...
>> 
>> The package seems to build fine on my system(s) with
>> 
>> R CMD build --compact-vignettes --resave-data=best pkg
>> 
>> (these are the R-forge build arguments, according to the r-forge
>> admins)
>> 
>> -- I've tried it with R-devel on Linux-32 and R 2.14.2 on
>> MacOS-64.
>> 
>> The build log (basically identical across linux64/win64/macos64)
>> is as follows:
>> 
>> -------------- Thu Mar 29 20:15:21 2012: Building tarball for
>> package glmmADMB (SVN revision 204) using R version 2.14.2
>> (2012-02-29) ...
>> 
>> * checking for file 'glmmADMB/DESCRIPTION' ... OK * preparing
>> 'glmmADMB': * checking DESCRIPTION meta-information ... OK *
>> checking for LF line-endings in source and make files * checking
>> for empty or unneeded directories * looking to see if a
>> 'data/datalist' file should be added * re-saving image files 
>> Error in loadNamespace(name) : there is no package called
>> 'glmmADMB' Execution halted Run time: 0.51 seconds. ----------
>> 
>> so apparently the package is failing because it doesn't exist
>> (!!) I originally thought this was a circular dependency problem,
>> because glmmADMB and coefplot2 (another r-forge package) depended
>> on each other, but I have (at least for now) removed glmmADMB's
>> coefplot2 dependency.  As far as I can tell there are *no*
>> packages on r-forge that depend on/suggest/import glmmADMB.
>> 
>> a1<- available.packages(contriburl= 
>> contrib.url("http://r-forge.r-project.org"))
>>> rownames(a1)["glmmADMB" %in% a1[,"Suggests"]]
>> character(0)
>>> rownames(a1)["glmmADMB" %in% a1[,"Depends"]]
>> character(0)
>>> rownames(a1)["glmmADMB" %in% a1[,"Imports"]]
>> character(0)
>> 
>> The perhaps-relevant parts of the DESCRIPTION file: ========= 
>> BuildVignettes: no Description: Fits mixed-effects models using a
>> variety of distributions Imports: stats, nlme Depends: R (>=
>> 2.13), methods, MASS, R2admb Suggests: lattice, lme4, lme4.0,
>> coda, mlmRev, scapeMCMC, ggplot2, bbmle, pscl, knitr, car =====
>> 
>> The only other thing I can think of is backing up a few SVN 
>> revisions and seeing whether I can get back to a working version,
>> but I'd like to see if I can get it fixed by moving forward
>> rather than backward ...
>> 
>> 
>> For anyone who is intrigued and wants to investigate farther:
>> 
>> http://r-forge.r-project.org/R/?group_id=847 
>> http://r-forge.r-project.org/scm/?group_id=847
>> 
>> cheers Ben Bolker
>> 
>> ______________________________________________ 
>> R-devel at r-project.org mailing list 
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPdiHCAAoJED2whTVMEyK9pnAH/jfg9Sf7F1AMbnQZIzlkX4Ue
nkYqG+9Ec6B+c+z1dHv/pZGzhDKK+CT7H15GVTqzSgiJLRw8sWxsWeAEc1hDJLbs
m0tRykJvyaLVIuE4oBvZ19iwbFnS9r8CKbRJeZdHS589oI9uv4ugYE41jbqOExuD
uLAoQVOvemxcEaggyhA04ItHuVtXMhFMGCw+4AmI2LxsKuncuD5LJchUjnTsI9jm
TrV+nBKvQjsUxL9So5aCOTJmsv1+DrXQhz1DrkOo0A+bb7V9EeGefLC0SOFlxZFo
VLo4vRznUbAdA/iKWqu7vL2GImw9b9Wpc2CyyEqpCZ/y24mrmSnC0W7hhVdF030=
=reN8
-----END PGP SIGNATURE-----