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
On 29.03.2012 22: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 haltedUntested: Get rid of .First.lib and use .onAttach - you have a NAMESPACE. Uwe> 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
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-- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
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? - BrianI 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 <bbolker at 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 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