[R-pkg-devel] Possible R CMD check extensions (Was: Possibly mis-spelled words in DESCRIPTION)

Hadley Wickham h.wickham at gmail.com
Sun May 8 17:44:27 CEST 2016


On Sun, May 8, 2016 at 10:15 AM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:
> On 08/05/2016 10:47 AM, Dirk Eddelbuettel wrote:
>>
>>
>> On 8 May 2016 at 16:18, Uwe Ligges wrote:
>> | On 08.05.2016 16:13, carlos cinelli wrote:
>> | > How should I proceed in this case?
>> |
>> | Submit to CRAN.
>>
>> The deeper question is if 'we all' can have a conversation about extending
>> the directory layout / format to add things to the packaging
>> infrastructure.
>> What comes to mind is e.g.
>>
>>    - a spell-checker white list (per Carlos' initial email)
>>
>>    - more generally, 'white list' of warnings R CMD check can be quiet
>> about [1]
>>
>>    - more hooks, ie I would like to call roxygen2::roxygenize() as well as
>>      Rcpp::compileAttributes() when building
>>
>>    - [ This place intentionally left blank. Let me hear other proposals. ]
>>
>> We have a year to mess things up for R 3.4.0, so anybody else intereted in
>> working on this?
>>
>> Dirk
>>
>> [1] There is no point in telling me that Rcpp creates a shared library of
>> over 1 mb. It has been doing so for years.  C++ libraries have a
>> footprint.
>>
>
> This gets tricky.  You don't want to be told that your shared lib is over 1
> MB, but I'd imagine you'd like to know if it grew over 1000 MB. So really
> you'd like to tune that note rather than suppress it, just like Carlos would
> like a white list for the spell checker rather than suppressing the spell
> check entirely.
>
> And CRAN has accepted Rcpp even though it generates that note, so it
> probably wouldn't object if you set the limit high enough to suppress the
> note currently, but it would object if you tried to suppress the note
> entirely (because they don't want 1000 MB shared libs either, and don't want
> to have to check your package manually).
>
> So this would require work on CRAN's side to recognize when your requested
> suppressions are acceptable.  And I'm sure there would be arguments back and
> forth, which also suck up CRAN's time and energy.
>
> The technical implementation is much easier than the procedural one.

Agreed, but currently CRAN has an informal whitelist in their brains
which they have to remember when you resubmit a package.  It is
possible that we could come up with a system that makes life easier
for CRAN because they could see the whitelist in a standard format and
easily diff with the last submission.

This would also make life easier for people like me and Dirk who have
to run R CMD check on 1000's of downstream dependencies. We have no
idea whether or not we're seeing check issues that are expected or
need to be acted upon.

Hadley

-- 
http://hadley.nz



More information about the R-package-devel mailing list