CRAN has for some time had a policies page at http://cran.r-project.org/web/packages/policies.html and we would like to draw this to the attention of package maintainers. In particular, please - always send a submission email to CRAN at r-project.org with the package name and version on the subject line. Emails sent to individual members of the team will result in delays at best. - run R CMD check --as-cran on the tarball before you submit it. Do this with the latest version of R possible: definitely R 2.14.2, preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are able to give better diagnostics, e.g. for compiled code and especially on Windows. They may also have extra checks for recently uncovered problems.) Also, please note that CRAN has a very heavy workload (186 packages were published last week) and to remain viable needs package maintainers to make its life as easy as possible. Kurt Hornik Uwe Ligges Brian Ripley
One of the things I have noticed with the R 2.15.0 RC and --as-cran is that the I have to bump the version number of the working copy of my packages immediately after putting a version on CRAN, or I get an message about version suitability. This is probably a good thing for packages that I have changed, compared with my old habit of bumping the version number at arbitrary times, although the mechanics are a nuisance because I do not actually want to commit to the next version number at that point. For packages that I have not changed it is a bit worse, because I have to change the version number even though I have not yet made any changes to the package. This will mean, for example, that on R-forge it will look like there is a slightly newer version, even though there is not really. I am curious how other developers approach this. Is it better to not specify --as-cran most of the time? My feeling is that it is better to specify it all of the time so that I catch errors sooner rather than later, but maybe there is a better solution? Paul On 12-03-27 07:52 AM, Prof Brian Ripley wrote:> CRAN has for some time had a policies page at > http://cran.r-project.org/web/packages/policies.html > and we would like to draw this to the attention of package maintainers. > In particular, please > > - always send a submission email to CRAN at r-project.org with the package > name and version on the subject line. Emails sent to individual members > of the team will result in delays at best. > > - run R CMD check --as-cran on the tarball before you submit it. Do > this with the latest version of R possible: definitely R 2.14.2, > preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are > able to give better diagnostics, e.g. for compiled code and especially > on Windows. They may also have extra checks for recently uncovered > problems.) > > Also, please note that CRAN has a very heavy workload (186 packages were > published last week) and to remain viable needs package maintainers to > make its life as easy as possible. > > Kurt Hornik > Uwe Ligges > Brian Ripley > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On 27.03.2012 16:17, Paul Gilbert wrote:> One of the things I have noticed with the R 2.15.0 RC and --as-cran is > that the I have to bump the version number of the working copy of my > packages immediately after putting a version on CRAN, or I get an > message about version suitability. This is probably a good thing for > packages that I have changed, compared with my old habit of bumping the > version number at arbitrary times, although the mechanics are a nuisance > because I do not actually want to commit to the next version number at > that point. For packages that I have not changed it is a bit worse, > because I have to change the version number even though I have not yet > made any changes to the package. This will mean, for example, that on > R-forge it will look like there is a slightly newer version, even though > there is not really. > > I am curious how other developers approach this. Is it better to not > specify --as-cran most of the time? My feeling is that it is better to > specify it all of the time so that I catch errors sooner rather than > later, but maybe there is a better solution?--as-cran is modelled rather closely after the CRAN incoming checks. CRAN checks if a new version has a new version number. Of course, you can ignore its result if you do not want to submit. The idea of using --as-cran is to apply it before you actually submit. Some parts require network connection etc. Uwe> Paul > > On 12-03-27 07:52 AM, Prof Brian Ripley wrote: >> CRAN has for some time had a policies page at >> http://cran.r-project.org/web/packages/policies.html >> and we would like to draw this to the attention of package maintainers. >> In particular, please >> >> - always send a submission email to CRAN at r-project.org with the package >> name and version on the subject line. Emails sent to individual members >> of the team will result in delays at best. >> >> - run R CMD check --as-cran on the tarball before you submit it. Do >> this with the latest version of R possible: definitely R 2.14.2, >> preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are >> able to give better diagnostics, e.g. for compiled code and especially >> on Windows. They may also have extra checks for recently uncovered >> problems.) >> >> Also, please note that CRAN has a very heavy workload (186 packages were >> published last week) and to remain viable needs package maintainers to >> make its life as easy as possible. >> >> Kurt Hornik >> Uwe Ligges >> Brian Ripley >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:> CRAN has for some time had a policies page at > http://cran.r-project.org/web/packages/policies.html > and we would like to draw this to the attention of package maintainers. ?In > particular, please > > - always send a submission email to CRAN at r-project.org with the package > name and version on the subject line. ?Emails sent to individual members of > the team will result in delays at best. > > - run R CMD check --as-cran on the tarball before you submit it. ?Do > this with the latest version of R possible: definitely R 2.14.2, > preferably R 2.15.0 RC or a recent R-devel. ?(Later versions of R are > able to give better diagnostics, e.g. for compiled code and especially > on Windows. They may also have extra checks for recently uncovered > problems.) > > Also, please note that CRAN has a very heavy workload (186 packages were > published last week) and to remain viable needs package maintainers to make > its life as easy as possible. >Regarding the part about "warnings or significant notes" in that page, its impossible to know which notes are significant and which ones are not significant except by trial and error. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com
On 12-03-27 10:59 AM, Uwe Ligges wrote:> > > On 27.03.2012 16:17, Paul Gilbert wrote: >> One of the things I have noticed with the R 2.15.0 RC and --as-cran is >> that the I have to bump the version number of the working copy of my >> packages immediately after putting a version on CRAN, or I get an >> message about version suitability. This is probably a good thing for >> packages that I have changed, compared with my old habit of bumping the >> version number at arbitrary times, although the mechanics are a nuisance >> because I do not actually want to commit to the next version number at >> that point. For packages that I have not changed it is a bit worse, >> because I have to change the version number even though I have not yet >> made any changes to the package. This will mean, for example, that on >> R-forge it will look like there is a slightly newer version, even though >> there is not really. >> >> I am curious how other developers approach this. Is it better to not >> specify --as-cran most of the time? My feeling is that it is better to >> specify it all of the time so that I catch errors sooner rather than >> later, but maybe there is a better solution? > > > --as-cran is modelled rather closely after the CRAN incoming checks. > CRAN checks if a new version has a new version number. Of course, you > can ignore its result if you do not want to submit. The idea of using > --as-cran is to apply it before you actually submit. Some parts require > network connection etc. > > UweYes but, for example, will R-forge run checks with --as-cran, and thus give warnings for any package unchanged from the one on CRAN, or run without --as-cran, and thus not give a true indication of whether the package is good to submit? (No doubt R-forge will customise more, but I am trying to work out a strategy for my own automatic testing.) Paul> > > > >> Paul >> >> On 12-03-27 07:52 AM, Prof Brian Ripley wrote: >>> CRAN has for some time had a policies page at >>> http://cran.r-project.org/web/packages/policies.html >>> and we would like to draw this to the attention of package maintainers. >>> In particular, please >>> >>> - always send a submission email to CRAN at r-project.org with the package >>> name and version on the subject line. Emails sent to individual members >>> of the team will result in delays at best. >>> >>> - run R CMD check --as-cran on the tarball before you submit it. Do >>> this with the latest version of R possible: definitely R 2.14.2, >>> preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are >>> able to give better diagnostics, e.g. for compiled code and especially >>> on Windows. They may also have extra checks for recently uncovered >>> problems.) >>> >>> Also, please note that CRAN has a very heavy workload (186 packages were >>> published last week) and to remain viable needs package maintainers to >>> make its life as easy as possible. >>> >>> Kurt Hornik >>> Uwe Ligges >>> Brian Ripley >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel
On 27.03.2012 17:22, Paul Gilbert wrote:> > > On 12-03-27 10:59 AM, Uwe Ligges wrote: >> >> >> On 27.03.2012 16:17, Paul Gilbert wrote: >>> One of the things I have noticed with the R 2.15.0 RC and --as-cran is >>> that the I have to bump the version number of the working copy of my >>> packages immediately after putting a version on CRAN, or I get an >>> message about version suitability. This is probably a good thing for >>> packages that I have changed, compared with my old habit of bumping the >>> version number at arbitrary times, although the mechanics are a nuisance >>> because I do not actually want to commit to the next version number at >>> that point. For packages that I have not changed it is a bit worse, >>> because I have to change the version number even though I have not yet >>> made any changes to the package. This will mean, for example, that on >>> R-forge it will look like there is a slightly newer version, even though >>> there is not really. >>> >>> I am curious how other developers approach this. Is it better to not >>> specify --as-cran most of the time? My feeling is that it is better to >>> specify it all of the time so that I catch errors sooner rather than >>> later, but maybe there is a better solution? >> >> >> --as-cran is modelled rather closely after the CRAN incoming checks. >> CRAN checks if a new version has a new version number. Of course, you >> can ignore its result if you do not want to submit. The idea of using >> --as-cran is to apply it before you actually submit. Some parts require >> network connection etc. >> >> Uwe > > Yes but, for example, will R-forge run checks with --as-cran, and thus > give warnings for any package unchanged from the one on CRAN, or run > without --as-cran, and thus not give a true indication of whether the > package is good to submit?This is a question for the R-forge maintainer. I would not expect it runs checks --as-cran, but I do now know. Best, Uwe> (No doubt R-forge will customise more, but I am trying to work out a > strategy for my own automatic testing.) > > Paul >> >> >> >> >>> Paul >>> >>> On 12-03-27 07:52 AM, Prof Brian Ripley wrote: >>>> CRAN has for some time had a policies page at >>>> http://cran.r-project.org/web/packages/policies.html >>>> and we would like to draw this to the attention of package maintainers. >>>> In particular, please >>>> >>>> - always send a submission email to CRAN at r-project.org with the package >>>> name and version on the subject line. Emails sent to individual members >>>> of the team will result in delays at best. >>>> >>>> - run R CMD check --as-cran on the tarball before you submit it. Do >>>> this with the latest version of R possible: definitely R 2.14.2, >>>> preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are >>>> able to give better diagnostics, e.g. for compiled code and especially >>>> on Windows. They may also have extra checks for recently uncovered >>>> problems.) >>>> >>>> Also, please note that CRAN has a very heavy workload (186 packages >>>> were >>>> published last week) and to remain viable needs package maintainers to >>>> make its life as easy as possible. >>>> >>>> Kurt Hornik >>>> Uwe Ligges >>>> Brian Ripley >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel
On 27.03.2012 17:09, Gabor Grothendieck wrote:> On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley > <ripley at stats.ox.ac.uk> wrote: >> CRAN has for some time had a policies page at >> http://cran.r-project.org/web/packages/policies.html >> and we would like to draw this to the attention of package maintainers. In >> particular, please >> >> - always send a submission email to CRAN at r-project.org with the package >> name and version on the subject line. Emails sent to individual members of >> the team will result in delays at best. >> >> - run R CMD check --as-cran on the tarball before you submit it. Do >> this with the latest version of R possible: definitely R 2.14.2, >> preferably R 2.15.0 RC or a recent R-devel. (Later versions of R are >> able to give better diagnostics, e.g. for compiled code and especially >> on Windows. They may also have extra checks for recently uncovered >> problems.) >> >> Also, please note that CRAN has a very heavy workload (186 packages were >> published last week) and to remain viable needs package maintainers to make >> its life as easy as possible. >> > > Regarding the part about "warnings or significant notes" in that page, > its impossible to know which notes are significant and which ones are > not significant except by trial and error.Right, it needs human inspection to identify false positives. We believe most package maintainers are able to see if he or she is hit by such a false positive. Uwe Ligges
2012/3/27 Uwe Ligges <ligges at statistik.tu-dortmund.de>:> > > On 27.03.2012 17:09, Gabor Grothendieck wrote: >> >> On Tue, Mar 27, 2012 at 7:52 AM, Prof Brian Ripley >> <ripley at stats.ox.ac.uk> ?wrote: >>> >>> CRAN has for some time had a policies page at >>> http://cran.r-project.org/web/packages/policies.html >>> and we would like to draw this to the attention of package maintainers. >>> ?In >>> particular, please >>> >>> - always send a submission email to CRAN at r-project.org with the package >>> name and version on the subject line. ?Emails sent to individual members >>> of >>> the team will result in delays at best. >>> >>> - run R CMD check --as-cran on the tarball before you submit it. ?Do >>> this with the latest version of R possible: definitely R 2.14.2, >>> preferably R 2.15.0 RC or a recent R-devel. ?(Later versions of R are >>> able to give better diagnostics, e.g. for compiled code and especially >>> on Windows. They may also have extra checks for recently uncovered >>> problems.) >>> >>> Also, please note that CRAN has a very heavy workload (186 packages were >>> published last week) and to remain viable needs package maintainers to >>> make >>> its life as easy as possible. >>> >> >> Regarding the part about "warnings or significant notes" in that page, >> its impossible to know which notes are significant and which ones are >> not significant except by trial and error. > > > > Right, it needs human inspection to identify false positives. We believe > most package maintainers are able to see if he or she is hit by such a false > positive.The problem is that a note is generated and the note is correct. Its not a false positive. But that does not tell you whether its "significant" or not. There is no way to know. One can either try to remove all notes (which may not be feasible) or just upload it and by trial and error find out if its accepted or not. -- Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com
On Tue, Mar 27, 2012 at 6:52 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:> CRAN has for some time had a policies page at > http://cran.r-project.org/web/packages/policies.html > and we would like to draw this to the attention of package maintainers. ?In > particular, pleaseThanks for the pointer - I did not know that this page existed. In general, is there some easy way to track changes to this page and the R extension manual over time? It is difficult to keep track of the best practices. I'd also like to get clarification on "Packages should not write in the users' home filespace, nor anywhere else on the file system apart from the R session's temporary directory (or during installation in the location pointed to by TMPDIR: and such usage should be cleaned up)." - what is recommended practice for packages to maintain state across instances? Operating systems have standards for where applications can store settings (e.g. as described in http://pypi.python.org/pypi/appdirs/1.2.0). Is it acceptable to for packages to follow these conventions? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/
Lots of very sensible policies here. I have one request as someone
who has in several cases had to involve company lawyers over
intellectual property issues with packages on CRAN -- the first bullet
point on ownership of copyright and intellectual property rights could
be strengthened further.
To the existing text "The ownership of copyright and intellectual
property rights of all components of the package must be clear and
unambiguous (including from the authors specification in the
DESCRIPTION file). Where code is copied (or derived) from the work of
others (including from R itself), care must be taken that any
copyright statements are preserved and authorship is not
misrepresented.
Trademarks must be respected."
I would add a few additional points :
1. The text of the license itself should be included in the package in
a LICENSE or COPYING file, as most of these licenses have things that
need to be filled in with names and other data, and just referencing a
license name in the DESCRIPTION file is not really a great way to deal
with licensing metadata when used exclusively (it's a great complement
to a full, filled-out license in the package itself).
2. Per file copyright comment headers can help immensely with ensuring
compliance and the accidental incorporation of files under a different
license. Comment header blocks with the author name and terms of
distribution could be recommended for all source files.
- Murray
On Tue, Mar 27, 2012 at 4:52 AM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:> CRAN has for some time had a policies page at
> http://cran.r-project.org/web/packages/policies.html
> and we would like to draw this to the attention of package maintainers. ?In
> particular, please
>
> - always send a submission email to CRAN at r-project.org with the package
> name and version on the subject line. ?Emails sent to individual members of
> the team will result in delays at best.
>
> - run R CMD check --as-cran on the tarball before you submit it. ?Do
> this with the latest version of R possible: definitely R 2.14.2,
> preferably R 2.15.0 RC or a recent R-devel. ?(Later versions of R are
> able to give better diagnostics, e.g. for compiled code and especially
> on Windows. They may also have extra checks for recently uncovered
> problems.)
>
> Also, please note that CRAN has a very heavy workload (186 packages were
> published last week) and to remain viable needs package maintainers to make
> its life as easy as possible.
>
> Kurt Hornik
> Uwe Ligges
> Brian Ripley
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
On 03/29/2012 05:00 AM, r-devel-request at r-project.org 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.The survival package has a similar special case: the routines for expected population survival are set up to accept multiple types of date format so have lines like if (class(x) == 'chron') { y <- as.numeric(x - chron("01/01/1960")} This leaves me with two extraneous "no visible binding" messages. There used to be half a dozen but I've tried to remove as many as possible, for all the good reasons already articulated by the maintainers. It still remains that 99/100 of the "no visible binding" messages I've seen over the years were misspelled variable names, and the message is a very welcome check. Terry Therneau
Paul,> One of the things I have noticed with the R 2.15.0 RC and --as-cran is > that the I have to bump the version number of the working copy of my[snip]> > I am curious how other developers approach this.Regardless of --as-cran I find it very useful to use the date as minor part of the version number (e.g. hyperSpec 0.98-20120320), which I set automatically. Claudia -- Claudia Beleites Spectroscopy/Imaging Institute of Photonic Technology Albert-Einstein-Str. 9 07745 Jena Germany email: claudia.beleites at ipht-jena.de phone: +49 3641 206-133 fax: +49 2641 206-399