From bbolker at gmail.com  Sat Mar 31 02:47:59 2012
From: bbolker at gmail.com (Ben Bolker)
Date: Fri, 30 Mar 2012 20:47:59 -0400
Subject: [Rd] r-forge build failure bafflement
In-Reply-To: <74449668-a1fa-4f83-9f4e-81707c0827bb@email.android.com>
References: <4F74CC1C.30802@gmail.com> <4F7546BC.70508@stats.ox.ac.uk>
	<4F7621C2.5070903@gmail.com>
	<74449668-a1fa-4f83-9f4e-81707c0827bb@email.android.com>
Message-ID: <4F76543F.3060206@gmail.com>

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 <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



[Rd] r-forge build failure bafflement
Ben Bolker