[Rd] no visible binding for global variable for data sets in a package

[peter dalgaard]

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 <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'
> 
>> 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 at 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.mes at cbs.dk  Priv: PDalgd at gmail.com