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:
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:
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 <maechler at stat.math.ethz.ch>
wrote:
Michael Friendly <friendly at 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'
## 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