R devel - Sep 2013 - declaring package dependencies

I received the following email note re: the vcdExtra package
> A vcd update has shown that packages TIMP and vcdExtra are not 
> declaring their dependence on colorspace/MASS: see
>
> http://cran.r-project.org/web/checks/check_results_vcdExtra.html
But, I can't see what to do to avoid this, nor understand what has 
changed in R devel.

Sure enough, CRAN now reports errors in examples using MASS::loglm(), 
using R Under development (unstable) (2013-09-11 r63906)

 > Caesar.mod0 <- loglm(~Infection + (Risk*Antibiotics*Planned), 
data=Caesar)
Error: could not find function "loglm"

In DESCRIPTION I have
Depends: R (>= 2.10), vcd, gnm (>= 1.0.3)
Suggests: 
ca,gmodels,Fahrmeir,effects,VGAM,plyr,rgl,lmtest,MASS,nnet,ggplot2,Sleuth2,car

and the vcd DESCRIPTION has

Depends: R (>= 2.4.0), grid, stats
Suggests: KernSmooth, mvtnorm, kernlab, HSAUR, coin
Imports: utils, MASS, grDevices, colorspace

so, in an R 3.0.0 console, library(vcdExtra) loads vcd and its dependencies:

 > library(vcdExtra)
Loading required package: vcd
Loading required package: MASS
Loading required package: grid
Loading required package: colorspace
Loading required package: gnm
Warning messages:
1: package ?vcd? was built under R version 3.0.1
2: package ?MASS? was built under R version 3.0.1
 >

Note: these CRAN errors do not occur on R-Forge, using R version 3.0.1 
Patched (2013-08-21 r63645)
and the latest devel version (0.5-11) of vcdExtra.

-Michael

-- 
Michael Friendly     Email: friendly AT yorku DOT ca
Professor, Psychology Dept. & Chair, Quantitative Methods
York University      Voice: 416 736-2100 x66249 Fax: 416 736-5814
4700 Keele Street    Web:   http://www.datavis.ca
Toronto, ONT  M3J 1P3 CANADA

Michael

(Several of us are struggling with these changes, so my comments are 
from the newly initiated point of view, rather than the fully 
knowledgeable.)

On 13-09-12 09:38 AM, Michael Friendly wrote:
> I received the following email note re: the vcdExtra package
>
>> A vcd update has shown that packages TIMP and vcdExtra are not
>> declaring their dependence on colorspace/MASS: see
>>
>> http://cran.r-project.org/web/checks/check_results_vcdExtra.html
> But, I can't see what to do to avoid this, nor understand what has
> changed in R devel.
Lots in this respect.
>
> Sure enough, CRAN now reports errors in examples using MASS::loglm(),
> using R Under development (unstable) (2013-09-11 r63906)
>
>  > Caesar.mod0 <- loglm(~Infection + (Risk*Antibiotics*Planned),
> data=Caesar)
> Error: could not find function "loglm"
>
> In DESCRIPTION I have
> Depends: R (>= 2.10), vcd, gnm (>= 1.0.3)
The "modern" way of thinking about this is that the Depends line
should
not have much in it, only things from other packages that you want 
directly available to the user. (There are a few other exceptions 
necessary for packages that have not themselves embraced the "modern" 
way.) Since you may want users of vcdExtra to automatically have access 
to functions in vcd, without needing to execute library(vcd), this 
classifies as one of the official exceptions and you probably want cvd 
in the Depends line. However, chances are that gnm should be in 
Imports:. If vcd is in the Depends line then it is automatically 
attached and your examples do not need library(vcd) or requires(vcd).

The Note

   Unexported object imported by a ?:::? call: ?vcd:::rootogram.default?

is harder to decide how to deal with. (This is sill just a note, but it 
looks to me like a note that will soon become a warning or error.) The 
simple solution is to export rootogram.default from vcd, but that 
exposes it to all users, and really you may just want to expose it to 
packages like vcdExtra. There was some recent discussion about this on 
R-devel. I suggested one possibility would be some sort of limited 
export. Since that was a suggestion that required work by someone else, 
it probably went the same place as most of those suggestion do. The 
solution I have adopted for the main case where this causes me problems 
is to split the classes, generics, and methods into one package, and the 
user functions into another. For example, if you have rootogram.default 
in a package called vcdClasses and exported it, then both vcd and 
vcdExtra can import it, but if it is not in their Depends line then it 
will not be visible to a user that executes library(vcd) or 
library(vcdExtra).

Beware that there is currently a small gotcha if the generics are S3, 
which was discussed recently and a patch submitted by Henrik Bengtsson 
(See Re: [Rd] "False" warning on "replacing previous import"
when
re-exporting identical object .)


Although there has been much moaning about these changes, including my 
own, I think the general logic is a real improvement. The way I think of 
it, the namespace imports for a package provide the equivalent of a 
search path for functions in the package, which is not changed by what 
packages a user or other packages attach or import. Thus a package 
developer has much more certain control over where the functions used by 
the package will come from. This is a trade-off for safety rather than 
convenience, thus the moaning. I am a complete newbie on this, but there 
seems to be a pretty good unofficial description at 
http://obeautifulcode.com/R/How-R-Searches-And-Finds-Stuff/.
> Suggests:
>
ca,gmodels,Fahrmeir,effects,VGAM,plyr,rgl,lmtest,MASS,nnet,ggplot2,Sleuth2,car
If it is only in Suggests you can refer to it in the example by 
MASS::loglm(), or require(MASS)/library(MASS). (I might have that wrong, 
at least one works but I'm not certain of both.)
>
>
> and the vcd DESCRIPTION has
>
> Depends: R (>= 2.4.0), grid, stats
> Suggests: KernSmooth, mvtnorm, kernlab, HSAUR, coin
> Imports: utils, MASS, grDevices, colorspace
Probably grid and stats should be in Imports.
>
> so, in an R 3.0.0 console, library(vcdExtra) loads vcd and its
> dependencies:
>
>  > library(vcdExtra)
> Loading required package: vcd
> Loading required package: MASS
> Loading required package: grid
> Loading required package: colorspace
> Loading required package: gnm
> Warning messages:
> 1: package ?vcd? was built under R version 3.0.1
> 2: package ?MASS? was built under R version 3.0.1
>  >
>
> Note: these CRAN errors do not occur on R-Forge, using R version 3.0.1
Are you actually getting anything to build on R-forge? All my packages 
have been stuck for a couple of weeks, as have many others.

Paul
> Patched (2013-08-21 r63645)
> and the latest devel version (0.5-11) of vcdExtra.
>
> -Michael
>

On 12/09/2013 9:38 AM, Michael Friendly wrote:
> I received the following email note re: the vcdExtra package
>
> > A vcd update has shown that packages TIMP and vcdExtra are not
> > declaring their dependence on colorspace/MASS: see
> >
> > http://cran.r-project.org/web/checks/check_results_vcdExtra.html
> But, I can't see what to do to avoid this, nor understand what has
> changed in R devel.
>
> Sure enough, CRAN now reports errors in examples using MASS::loglm(),
> using R Under development (unstable) (2013-09-11 r63906)
>
>   > Caesar.mod0 <- loglm(~Infection + (Risk*Antibiotics*Planned),
> data=Caesar)
> Error: could not find function "loglm"
I think this one would be fine if you had library(MASS) or require(MASS) 
or (probably best) used MASS::loglm explicitly.  It may be that in the 
past some other package put MASS on the search list, and that's why it 
worked before.

The distinction is between "loading" and "attaching" a
package. Loading
it (which would be done if you had MASS::loglm, or imported it) 
guarantees that the package is initialized and in memory, but doesn't 
make it visible to the user without the explicit MASS:: prefix.  
Attaching it first loads it, then modifies the user's search list so the 
user can see it.

Loading is less intrusive, so it's preferred over attaching.  Both 
library() and require() would attach it.

Duncan Murdoch
>
> In DESCRIPTION I have
> Depends: R (>= 2.10), vcd, gnm (>= 1.0.3)
> Suggests:
>
ca,gmodels,Fahrmeir,effects,VGAM,plyr,rgl,lmtest,MASS,nnet,ggplot2,Sleuth2,car
>
> and the vcd DESCRIPTION has
>
> Depends: R (>= 2.4.0), grid, stats
> Suggests: KernSmooth, mvtnorm, kernlab, HSAUR, coin
> Imports: utils, MASS, grDevices, colorspace
>
> so, in an R 3.0.0 console, library(vcdExtra) loads vcd and its
dependencies:
>
>   > library(vcdExtra)
> Loading required package: vcd
> Loading required package: MASS
> Loading required package: grid
> Loading required package: colorspace
> Loading required package: gnm
> Warning messages:
> 1: package ?vcd? was built under R version 3.0.1
> 2: package ?MASS? was built under R version 3.0.1
>   >
>
> Note: these CRAN errors do not occur on R-Forge, using R version 3.0.1
> Patched (2013-08-21 r63645)
> and the latest devel version (0.5-11) of vcdExtra.
>
> -Michael
>

I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and 
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the 
CRAN policies advise.  winbuilder's R-devel seems to be built daily, 
saving me the time. Since I don't have Windows it kills two birds with 
one stone.  It has caught many problems for me before submitting to CRAN 
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit 
to CRAN rather than an ftp upload to incoming.  Only if winbuilder 
passed "OK" on R-devel could it then go to a human.   But iirc there
was
a technical difficulty preventing this.

Matthew



	[[alternative HTML version deleted]]

I'm a little surprised by this thread.

I subscribe to the RSS feeds of changes to NEWS (as Dirk mentioned) and 
that's been pretty informative in the past :
http://developer.r-project.org/RSSfeeds.html

Mainly though, I submit to winbuilder before submitting to CRAN, as the 
CRAN policies advise.  winbuilder's R-devel seems to be built daily, 
saving me the time. Since I don't have Windows it kills two birds with 
one stone.  It has caught many problems for me before submitting to CRAN 
and I can't remember it ever not responding in a reasonable time.
http://win-builder.r-project.org/upload.aspx

I've suggested before that winbuilder could be the mechanism to submit 
to CRAN rather than an ftp upload to incoming.  Only if winbuilder 
passed OK on R-devel could it then go to a human.   But iirc there was a 
technical difficulty preventing this.

Matthew

On Sep 16, 2013, at 01:46 PM, Brian Rowe wrote:
> That reminds me: I once made a suggestion on how to automate some of the
CRAN
> deployment process, but it was shot down as not being useful to them. I do
> recall a quote that was along the lines of "as long as you don't
need help,
> do whatever you want", so one thought is to just set up a build server
that
> does the building across the three versions of R, checks dependencies,
rebuilds
> when release, patch, or devel are updated, etc. This would ease the burden
on
> package maintainers and would just happen to make the CRAN folks' lives
easier
> by catching a lot of bad builds. A proof of concept on AWS connecting to
github
> or rforge could probably be finished on a six-pack. Speak up if anyone
thinks
> this would be useful.
Yes useful. But that includes a package build system (which is what breaks on
R-Forge). If you could do that on a six-pack then could you fix R-Forge on a
three-pack first please? The R-Forge build system is itself an open source
package on R-Forge. Anyone can look at it, understand it and change it to be
more stable. That build system is here :

https://r-forge.r-project.org/R/?group_id=34

(I only know this because Stefan told me once. So I suspect others don't
know
either, or it hasn't sunk in that we're pushing on an open door.)

Matthew

Ben Bolker wrote :
> Do you happen to remember what the technical difficulty was?
 From memory I think it was that CRAN maintainers didn't have
access to Uwe's winbuilder machine. But often when I get OK
from winbuilder R-devel I don't want it to go to CRAN yet. So
procedures and software would have to be put in place to
handle that (unclear) logic which I didn't propose anything
for or offer any code to do. So time and effort to decide and
time and effort to implement. Just a guess. And maybe some
packages don't run on Windows, so what about those?  It's
all those edge cases that really take the time.

Matthew