[Rd] NOTE: unstated dependencies in examples

[Duncan Murdoch]

On 15/10/2011 2:52 AM, Jari Oksanen wrote:
> Hello folks,
>
> To get it short, I cut out most of the spurious controversy, and go to the
> key point (and it also helps to go to sauna and then sleep well all night):
>
> On 14/10/11 22:30 PM, "Uwe Ligges"<ligges at statistik.tu-dortmund.de>  wrote:
>
> >
> >  Also note that the package would be accepted on CRAN as is, if you
> >  declared "parallel" as a Suggests, as far as I understand Jari. At least
> >  binaries for Windows for old R versions will be built, since I am
> >  checking with
> >  _R_CHECK_FORCE_SUGGESTS_=FALSE
> >  on Windows.  Therefore, I believe (I haven't seen the package) this
> >  discussion is meaningless anyway.
>
> This is fine and solve the problems I anticipated. I did not know about this
> possibility. It was not shown in R CMD check --help, nor in the usual
> manuals I read: it seems to be mentioned in R-ints.texi, but not in
> R-exts.texi nor in R-admin.texi.
>
> Although I feel well at the moment, I return to the old team: about the kind
> of keyword describing packages that you don't necessarily need, and which
> are used in style
>
> if(require(foo)) {do_something_fancy_with_foo::foo()}
>
> They are "Sugar: parallel, foo". They are not necessarily needed, if you
> don't have you don't necessarily even know you need them.

That is exactly what Suggests is for.

The checks are designed to check that your code doesn't have errors like 
the one in the sample above.  If they can't find the suggested package, 
they can't check it.  That is why suggested packages need to be 
available for the checks.

Duncan Murdoch

> Then about old R and new packages: many of us are in situations where we
> must use an old version of R. However, we can still install packages in
> private libraries without admin privileges. They may not be system-wide, and
> they can be wiped out in the next boot, or you may need to have them in your
> USB stick, but installing a package is rather a light operation  which can
> be be done except in most paranoid systems. One year I burned an R
> installation to a CD that I distributed to the students so that they could
> run R in a PC class with too ancient R. In one occasion I gave students
> temporary usernames to my personal Linux desktop so that they could log in
> to my desktop from the class for one analysis (but that is in general too
> clumsy as Windows did not have good X11).
>
> New package versions can contain bug fixed and some enhanced functionality
> in addition to radical new features that require bleeding edge R.
> Personally, I try to keep my release versions such that they work in
> current, previous and future major versions of R. Currently I test the
> package more or less regularly in R 2.13.2 and R-to-be-2.14.0 in MacOS, and
> in 2.12.2 and R-to-be-2.15.0 in Linux, and I expect the release version to
> pass all these. The development version can fail in older R, but then we
> (the team) must judge if we merge such failing features to the release.
>
> Cheers, Jari Oksanen
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel