[Rd] couldn't find function "setClass"

[Prof Brian Ripley]

On Tue, 16 Sep 2003, John Chambers wrote:

> Kurt Hornik wrote:
> > 
> > >>>>> John Chambers writes:
> > 
> > > Prof Brian Ripley wrote:
> > >>
> > >> On Tue, 16 Sep 2003, John Chambers wrote:
> > >>
> > >> > Jeff Gentry wrote:
> > >> > >
> > >> > > Hello ...
> > >> > >
> > >> > > With a new checkout of R-devel (last update was 2003-09-11) we are having
> > >> > > a problem (it seems to be happening to all of us here on a few different
> > >> > > machines) where during install/check/etc when the 'save image' happens (in
> > >> > > packages using 'save image'):
> > >> > >
> > >> > > ** save image
> > >> > > Error: couldn't find function "setClass"
> > >> > > Execution halted
> > >> > >
> > >> > > This is for all packages that are using classes.
> > >> > >
> > >> > > Is anyone else having this problem?
> > >> >
> > >> > With packages that do NOT have a namespace but DO have saved images,
> > >> > yes. (!)
> > >> >
> > >> > The problem seems to be that the current version of INSTALL doesn't end
> > >> > up with library(methods) in this branch (related to --vanilla ?).  One
> > >>
> > >> It's not related to --vanilla, which does not change the packages loaded.
> > >> See Kurt's comment for what I believe is the true reason.
> > >>
> > >> > workaround seem to be to change INSTALL (or scripts/INSTALL.in) as
> > >> > follows:
> > >> >
> > >> > 522c522
> > >> > <       code_cmd="eval cat \"${code_file}\""
> > >> > ---
> > >> > >       code_cmd="eval echo \"library(methods)\"; cat \"${code_file}\""
> > >> >
> > >> > to explicitly attach the library.  This may in fact be the right fix,
> > >> > but I'm confused as to why this is happening now.
> > >>
> > >> I don't think so: methods is currently optional and Doug's fix seems to be
> > >> to be the right one.
> > 
> > > That (apparently) the problem arises in such a special situation is
> > > confusing for users.  At least for me, it's ONLY in the combination of
> > > saved image and no namespace.
> > 
> > > That the user does not need a require(methods) when testing the code
> > > directly but does (sometimes) when the source code is in package
> > > source is not a feature.  If we can avoid this complexity, that would
> > > encourage package developers.
> > 
> > Unfortunately, it is not necessarily true that require(methods) is not
> > needed when testing: site admins or "users" might have changed the
> > default packages from the system default.
> 
> Indeed, but then the user would always see things this way.  Consistency
> makes people feel more secure.
> 
> > 
> > Otoh, once we use --vanilla for the save image creation, it seems that
> > this eliminates all (reasonable) possibilities for changing the default
> > packages (or am I missing something?).  So we could use the system
> > default rather than just base here.
> 
> Intuitively, --vanilla means "the standard flavor", as opposed to
> --stripped, say, so it would seem more natural to have the system
> defaults wherever possible.

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

gannet% env R_DEFAULT_PACKAGES=ts R --vanilla

really does load only "package:ts".

>From ?Startup

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

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


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595