On 12-03-30 08:14 PM, Brian G. Peterson wrote: > On my phone, so replying off-list, but wouldn't loading the data > objects in a running R session and using the appropriate > compression arguments to save() do the trick? - Brian
I might try that, but I have a strong suspicion that R will try to load the data objects anyway to see if they are compressible ... I'd have to look more carefully at resaveRdaFiles (in src/library/tools/admin.R) to be sure, but it looks like line 860 suppressPackageStartupMessages(load(p, envir = env)) unconditionally loads the files and would trigger the search for the package -- I don't think this is avoidable. [cc'd back to r-devel for discussion/archival purposes] > -- Sent from my Android phone with K-9 Mail. Please excuse my > brevity. > > Ben Bolker <bbol...@gmail.com> wrote: > > 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, e! rror 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 >>> someo! > ne 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-informatio! > n ... 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 >>> forwar! > d >>> 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@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