[Rd] couldn't find function "setClass"

[Kurt Hornik]

>>>>> Prof Brian Ripley writes:

> 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.

In fact, to answer to my previous question: yes, I was missing
something.  Even with --vanilla in place, site admins and users can
change the default packages via the environment variable
R_DEFAULT_PACKAGES, overriding the system defaults.

I am sympathetic with the idea of using the *system* defaults when
creating the save image, but how can we achieve that?  (I.e., ignore or
override values of R_DEFAULT_PACKAGES from the environment, in addition
to --vanilla ...)

-k