Re solution 2, the following is in the function tabFarsDead()
the latest (0.55) version of gamclass:
data('FARS', package='gamclass', envir=environment())
FARS <- get("FARS", envir=environment())
The second statement is, strictly, redundant, but it
makes the syntax checker happy. Another possibility
might be:
FARS <- NULL
data('FARS', package='gamclass', envir=environment())
I do not know whether this passes.
An FAQ that offers preferred solutions to such chestnuts,
or a web page, or a blog, would seem to me useful.
John Maindonald email:
john.maindon...@anu.edu.au<mailto:john.maindon...@anu.edu.au>
phone : +61 2 (6125)3473 fax : +61 2(6125)5549
Centre for Mathematics & Its Applications, Room 1194,
John Dedman Mathematical Sciences Building (Building 27)
Australian National University, Canberra ACT 0200.
On 27 Aug 2014, at 20:00,
<r-devel-requ...@r-project.org<mailto:r-devel-requ...@r-project.org>>
<r-devel-requ...@r-project.org<mailto:r-devel-requ...@r-project.org>> wrote:
From: Martin Maechler
<maech...@stat.math.ethz.ch<mailto:maech...@stat.math.ethz.ch>>
Subject: Re: [Rd] no visible binding for global variable for data sets in a
package
Date: 27 August 2014 19:24:36 AEST
To: Michael Friendly <frien...@yorku.ca<mailto:frien...@yorku.ca>>
Cc: r-devel <r-devel@r-project.org<mailto:r-devel@r-project.org>>
Reply-To: Martin Maechler
<maech...@stat.math.ethz.ch<mailto:maech...@stat.math.ethz.ch>>
Michael Friendly <frien...@yorku.ca<mailto: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
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
