Re: [Rd] CRAN policies

From: Dirk Eddelbuettel <>
Date: Thu, 29 Mar 2012 09:07:07 -0500

On 29 March 2012 at 07:58, Brian G. Peterson wrote:
| On Thu, 2012-03-29 at 16:52 +1300, Thomas Lumley wrote:
| > The 'No visible binding for global variable" is a good example. This
| > found some bugs in my 'survey' package, which I removed. There is
| > still one note of this type, which arises when I have to handle two
| > different versions of the hexbin package with different internal
| > structures. The note is a false positive because the use is guarded
| > by an if(), but CMD check can't tell this. So, it's a good idea to
| > remove all Notes that can be removed without introducing other code
| > problems, which is nearly all of them, but occasionally there may be a
| > good reason for code that produces a Note.
| >
| 'occasionally' seems like an understatement.
| Here's an example:
| data(cars)
| lm(speed ~ dist,cars) #would produce global variables NOTE
| lm("speed ~ dist",cars) # would not produce the NOTE
| While the change required to avoid the CRAN NOTE is small, I can't think
| of a single example or text on using formulas that recommends quoting
| the formula as a best practice. I'm not sure how users or package
| authors are supposed to know that they should use a (non standard) way
| of specifying the formula to avoid wasting their time, and the CRAN
| volunteers time. I'm certain that there are many other examples, but
| this one was easy to demonstrate.

And it's close to my personal favourite of

    with( cars, ... some expression involving dist and / or speed ... )

which gives the same warning about dist and speed being unknown globals. Punishment for good coding style -- gotta love it.

Now, we all want high-quality packages.

We all strive to have as few false positives.

And we all understand that writing a parser if freaking hard.

One fudge-y way of helping with this may be via an overrides file.

This is what Debian does to suppress known / tolerated violations of what the 'lintian' package checker picks up on. For the R package, I have a fair number of these: the file for the r-base-core binary is currently 83 lines long and this ends on

  r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rdiff
  r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/mai.png
  r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/oma.png
  r-base-core: image-file-in-usr-lib usr/lib/R/library/graphics/help/figures/pch.png
  r-base-core: executable-not-elf-or-script usr/lib/R/bin/Rd2pdf

two warnings on files with 755 modes in a non-PATH location (fine, that's how R works) and idem with image files below /usr/lib (when the FHS probably prefers them below /usr/share/).

You pipe the output of a lintian run into 'lintian-info' and you get longer one or two paragraph descriptions with further pointers on the violations.

Does this sounds like something worthwhile to add to the R CMD check system ?

Should we consider to allow overrides to make known good exceptions good away?


R/Finance 2012 Conference on May 11 and 12, 2012 at UIC in Chicago, IL
See agenda, registration details and more at

______________________________________________ mailing list
Received on Thu 29 Mar 2012 - 14:12:15 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Thu 29 Mar 2012 - 16:50:36 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive