[R-pkg-devel] Is S3 class registration essential for CRAN?

Henrik Bengtsson henrik.bengtsson at gmail.com
Wed Jul 13 17:35:43 CEST 2016


I second Dirk.  Also, from my experience:

A good rule of thumb is that you should fix all NOTEs (i.e. not have
them) when you submit to CRAN.  It's only when you have a really good
reason you could try to convince CRAN that they are there and that
they cannot be fixed easily.  I've got 20+ packages on CRAN and it's
been extremely rare that I ran into a NOTE that I couldn't fix.

Importantly, I'd assume that if your submission has issues (i.e.
ERRORs, WARNINGs or NOTEs), then CRAN needs to look at your package
manually and make a decision and most likely write you an email.  Even
if that would be a 2 min task (but I'd assume it's more) that's lots
of time spent on their end given they get so many submission every
day.  If your submission has all OKs, then it's much more likely that
your package is accepted and on CRAN very quickly (definitely < 24
hours; likely < 12 hours by my experience).  So, aim for all OKs to
save you and CRAN some time.


Registering S3 methods is as simple as specifying

S3method("mtd", "clss")

in the NAMESPACE file (for all your S3 methods).  If you use roxygen2,
this becomes nearly automatic.  It'll also improve the quality of your
package, e.g. make it play better with others.  I would certainly add
these.

Henrik


On Tue, Jul 12, 2016 at 10:13 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 12 July 2016 at 17:47, S Ellison wrote:
> | A short question: How necessary is explicit S3 class registration for CRAN submission?
> | R-forge's check is giving me a note on this for a handful of methods in a package, and I'm unclear whether it is something that _needs_  to be fixed for CRAN submission by registering all S3 methods, needs to be fixed for _some_, or doesn't need to be changed (the present version on cran is running without apparent issues, but was submitted before the checks expanded to pick this up).
>
> You are expected to test with the release and the development versions of R
> [1], and newer versions tend to only get stricter rather than more lenient.
>
> As for 'current version on CRAN does not have issues': well, yes, the absence
> of a time machine comes into play again. Tests that didn't exist at the time
> have a tendency to not get triggered.  Rest assurred that the _next_ upload
> will however so you are quite right to worry about this.
>
> So without knowing the pecularities of your (unnamed) package: I'd fix it.
>
> Dirk
>
>
> [1] Using win-builder can be a good trick to get access at the latter.
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>
> ______________________________________________
> 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