The change would seem to be this
\item \command{R CMD check} now by default checks code usage
directly on the package namespace without loading and attaching
the package and its suggests and enhances.
and perhaps the remedies could be stated more clearly?
Putting the data objects in the namespace would seem the obvious thing to do.
One oddity is that they are sort of in there already:
> Lahman::battingLabels
variable label
1 playerID Player ID code
2 yearID Year
3 stint Player's stint
4 teamID Team
5 lgID League
6 G Games
7 G_batting Games as batter
8 AB At Bats
9 R Runs
10 H Hits
11 X2B Doubles
12 X3B Triples
13 HR Homeruns
14 RBI Runs Batted In
15 SB Stolen Bases
16 CS Caught Stealing
17 BB Base on Balls
18 SO Strikeouts
19 IBB Intentional walks
20 HBP Hit by pitch
21 SH Sacrifice hits
22 SF Sacrifice flies
23 GIDP Grounded into double plays
24 G_Old Old version of games (deprecated)
But then again, actually not:
> Lahman::Label()
Error in rbind(battingLabels, pitchingLabels, fieldingLabels) :
object 'battingLabels' not found
This is documented (:: can access datasets made available by lazy-loading), but
it sort of suggests that we might want to improve consistency in this area.
-pd
On 27 Aug 2014, at 11:24 , Martin Maechler <maech...@stat.math.ethz.ch> wrote:
>>>>>> Michael Friendly <frien...@yorku.ca>
>>>>>> on Tue, 26 Aug 2014 17:58:34 -0400 writes:
>
>> I'm updating the Lahman package of baseball statistics to the 2013
>> release. In addition to
>> the main data sets, the package also contains several convenience
>> functions that make use
>> of these data sets. These now trigger the notes below from R CMD check
>> run with
>> Win builder, R-devel. How can I avoid these?
>
>> * using R Under development (unstable) (2014-08-25 r66471)
>> * using platform: x86_64-w64-mingw32 (64-bit)
>> ...
>> * checking R code for possible problems ... NOTE
>> Label: no visible binding for global variable 'battingLabels'
>> Label: no visible binding for global variable 'pitchingLabels'
>> Label: no visible binding for global variable 'fieldingLabels'
>> battingStats: no visible binding for global variable 'Batting'
>> battingStats: no visible global function definition for 'mutate'
>> playerInfo: no visible binding for global variable 'Master'
>> teamInfo: no visible binding for global variable 'Teams'
>
>> One such function:
>
>> ## function for accessing variable labels
>
>> Label <- function(var, labels=rbind(battingLabels, pitchingLabels,
>> fieldingLabels)) {
>> wanted <- which(labels[,1]==var)
>> if (length(wanted)) labels[wanted[1],2] else var
>> }
>
> and you are using the data sets you mentioned before,
> (and the checking has been changed recently here).
>
> This is a bit subtle:
> Your data sets are part of your package (thanks to the default
> lazyData), but *not* part of the namespace of your package.
> Now, the reasoning goes as following: if someone uses a function
> from your package, say Label() above,
> by
> Lahman::Label(..)
> and your package has not been attached to the search path,
> your user will get an error, as the datasets are not found by
> Label().
>
> If you consider something like Lahman::Label(..)
> for a bit and the emphasis we put on R functions being the
> primary entities, you can understand the current, i.e. new,
> R CMD check warnings.
>
> I see the following two options for you:
>
> 1) export all these data sets from your NAMESPACE
> For this (I thinK), you must define them in Lahman/R/ possibly via a
> Lahman/R/sysdata.rda
>
> 2) rewrite your functions such that ensure the data sets are
> loaded when they are used.
>
>
> "2)" actually works by adding
> stopifnot(require(Lahman, quietly=TRUE))
> as first line in Label() and other such functions.
>
> It works in the sense that Lahman::Label("yearID") will
> work even when Lahman is not in the search path,
> but R-devel CMD check will still give the same NOTE,
> though you can argue that that note is actally a "false positive".
>
> Not sure about another elegant way to make "2)" work, apart from
> using data() on each of the datasets inside the
> function. As I haven't tried it, that may *still* give a
> (false) NOTE..
>
> This is a somewhat interesting problem, and I wonder if everyone
> else has solved it with '1)' rather than a version of '2)'.
>
> Martin
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd....@cbs.dk Priv: pda...@gmail.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
