[Rd] NOTE: unstated dependencies in examples

[Jari Oksanen]

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.

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