[R-pkg-devel] CRAN pretest archived because of 2 NOTEs

Ben Bolker bbolker at gmail.com
Wed Apr 18 22:00:30 CEST 2018

  Your points are well taken, but it's also necessary (IMO) for the CRAN
maintainers to have some flexibility, while still being able to hold
package maintainers to account.

   Long-time package maintainers (like you) have some issues that new
submitters don't; the large-component check was "only" instituted three
years ago
 As Duncan suggested,
CRAN maintainers are more likely to make allowances for long-time
maintainers ...

  In the spirit of your suggestion, I would say I'd like to see the
information provided by Dirk at
<http://dirk.eddelbuettel.com/blog/2017/08/10/> about providing
defaults/exceptions for the spell-checker made public/official --
several recent posts have shown package maintainers getting distracted
by spell-check false positives and missing potentially more serious
NOTEs.  (This information may exist elsewhere, but I couldn't find it
either in "Writing R Extensions" or the CRAN Repository Policy ...)

On 2018-04-18 02:13 PM, J C Nash wrote:
> If NOTEs are going to be treated as errors, then a lot of infrastructure (all my
> packages for optimization and nonlinear modelling, which are dependencies of
> a few dozen other packages etc.) will disappear. This is because they have version
> numbering I've been using in some form that pre-dates R and uses YYYY-M(M).D(D).
> e.g., NOTE "Version contains large components (2018-3.28)"
> I believe changing it to a "smaller" value will mean the submission is refused
> on an ERROR since the numbering will be out of order.
> So perhaps it is time either to revisit NOTEs to drop some unnecessary ones,
> and also to make some careful decisions and change critical ones to WARNINGs or
> One of the major concerns I have is that it is desirable that CRAN be the
> true repository for R packages, and that increased restrictions -- especially
> if unnecessary -- will surely increase the movement to informal distribution
> on other platforms like Github. Such fragmentation of the package universe
> weakens R as a resource, and we see quite a lot of this recently.
> I'm strongly in favour of having fairly strict standards, but also of ensuring
> that only necessary restrictions are enforced. Even more, I believe we must
> keep working to make satisfying the standards as easy as possible. R has done
> a good job of this, but there is always room to improve.
> JN
> On 2018-04-18 01:40 PM, Hadley Wickham wrote:
>> For the purposes of CRAN submission, you should basically treat every
>> NOTE as an ERROR.
>> Hadley
>> On Wed, Apr 18, 2018 at 3:36 AM, Gertjan van den Burg
>> <gertjanvandenburg at gmail.com> wrote:
>>> While waiting to get this message posted to the list, I've solved the
>>> problem by copying the stdlib rand() and srand() functions into my package
>>> under a different name. This makes the check pass and ensures my RNG does
>>> not interfere with R's RNG.
>>> I do think that if this NOTE causes immediate dismissal of a package, it
>>> shouldn't be a NOTE but an ERROR. Otherwise it just leads to a lot of wasted
>>> time waiting for a reply from the maintainers to respond to the note.
>>>> Dear all,
>>>> My CRAN submission doesn't pass the pre-tests and gets archived. I've
>>>> emailed cran-submissions at r-project.org explaining that these are false
>>>> positives, but since I haven't heard back in 10 days I don't think anyone
>>>> read that. Same thing for the submission comments (which also explained
>>>> it).
>>>> The first note is:
>>>> * checking CRAN incoming feasibility ... NOTE
>>>> Maintainer: ‘Gertjan van den Burg <gertjanvandenburg at gmail.com>’
>>>> New submission
>>>> Possibly mis-spelled words in DESCRIPTION:
>>>>    GenSVM (8:18, 10:61, 15:2, 16:26, 19:11)
>>>>    Multiclass (4:22)
>>>>    SVMs (14:25, 15:42)
>>>>    misclassifications (11:49)
>>>>    multiclass (8:53, 14:14, 15:31)
>>>> These words are not mis-spelled, so this is a false positive.
>>>> The second note is:
>>>> * checking compiled code ... NOTE
>>>> File ‘gensvm/libs/gensvm_wrapper.so’:
>>>>    Found ‘rand’, possibly from ‘rand’ (C)
>>>>      Objects: ‘gensvm/src/gensvm_cv_util.o’, ‘gensvm/src/gensvm_init.o’,
>>>>        ‘gensvm/lib/libgensvm.a’
>>>>    Found ‘srand’, possibly from ‘srand’ (C)
>>>>      Objects: ‘gensvm/src/gensvm_train.o’, ‘gensvm/lib/libgensvm.a’
>>>> Compiled code should not call entry points which might terminate R nor
>>>> write to stdout/stderr instead of to the console, nor use Fortran I/O
>>>> nor system RNGs.
>>>> See ‘Writing portable packages’ in the ‘Writing R Extensions’ manual.
>>>> This is probably why the package is rejected. I have a valid use case for
>>>> using rand() and srand(): I'm trying to maintain compatibility of this
>>>> package with the corresponding Python package. By using rand en srand
>>>> users
>>>> can reproduce models in both languages.
>>>> Does anyone have any ideas on how I can get the package excepted to CRAN?
>>>> Thanks,
>>>> Gertjan van den Burg
>>> ______________________________________________
>>> R-package-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

More information about the R-package-devel mailing list