couldn't find function "setClass"

Martin Maechler writes:

"BDR" == Prof Brian Ripley <ripley@stats.ox.ac.uk>
    on Wed, 17 Sep 2003 07:05:57 +0100 (BST) writes:

    <..............>

JMC> That (apparently) the problem arises in such a
JMC> special situation is confusing for users.  At least
JMC> for me, it's ONLY in the combination of saved image
JMC> and no namespace.

JMC> That the user does not need a require(methods) when
JMC> testing the code directly but does (sometimes) when
JMC> the source code is in package source is not a
JMC> feature.  If we can avoid this complexity, that would
JMC> encourage package developers.

BDR> Unfortunately, it is not necessarily true that
BDR> require(methods) is not needed when testing: site
BDR> admins or "users" might have changed the default
BDR> packages from the system default.

JMC> Indeed, but then the user would always see things this
JMC> way.  Consistency makes people feel more secure.

BDR> Otoh, once we use --vanilla for the save image
BDR> creation, it seems that this eliminates all
BDR> (reasonable) possibilities for changing the default
BDR> packages (or am I missing something?).  So we could
BDR> use the system default rather than just base here.

JMC> Intuitively, --vanilla means "the standard flavor", as opposed to
JMC> --stripped, say, so it would seem more natural to have the system
JMC> defaults wherever possible.

BDR> As I have said before, --vanilla does not change the
BDR> default packages, nor the possibility of setting the
BDR> default packages at system level.

BDR> gannet% env R_DEFAULT_PACKAGES=ts R --vanilla

BDR> really does load only "package:ts".

BDR> From ?Startup

The command-line flag '--vanilla' implies
'--no-site-file', '--no-init-file', '--no-restore' and
'--no-environ'.

BDR> and let me add, nothing else.  It is possible for
BDR> sysadmins to change the system environment and profile
BDR> files, and some do.

Agreed.  
So this means we should do more than just "--vanilla".
In some cases, we already do set environment variables such as
LANG=C and so we should also be allowed to set
R_DEFAULT_PACKAGES to the standard default (rather than the
local installation one).

Done now.  It turns out that 'R_DEFAULT_PACKAGES=' does the job.

I also modified R CMD check to use the system default when running the
examples and specific tests (although running with
R_DEFAULT_PACKAGES=NULL seems to work for all CRAN packages).

-k