From Kurt.Hornik@ci.tuwien.ac.at  Tue Apr 10 08:33:00 2001
From: Kurt.Hornik@ci.tuwien.ac.at (Kurt Hornik)
Date: Tue, 10 Apr 2001 09:33:00 +0200
Subject: [Rd] Detaching "ctest"
In-Reply-To: <Pine.GSO.4.20.0104091419000.13680-100000@laplace>
References: <15057.44851.453347.367801@mithrandir.hornik.net>
 <Pine.GSO.4.20.0104091419000.13680-100000@laplace>
Message-ID: <15058.46892.196865.11757@mithrandir.hornik.net>

>>>>> Jonathan Rougier writes:

> On Mon, 9 Apr 2001, Kurt Hornik wrote:
>> >>>>> Jonathan Rougier writes:

>> > OK! if you put it like that, then I think that .First should
>> definitely > *not* be used for package set-up, as it prevents
>> .Rprofile commands from > being the last things executed before the
>> prompt, and thus removes > "complete user control" of the set-up.
>> 
>> Not sure if I understand this.
>> 
>> Upon startup,
>> 
>> * Then, unless `--no-init-file' was given, R searches for a file
>> called `.Rprofile' in the current directory or in the user's home
>> directory (in that order) and sources it.
>> 
>> * It also loads a saved image from `.RData' if there is one (unless
>> `--no-restore' or `--no-restore-data' was specified).
>> 
>> * Finally, if a function `.First' exists, it is executed.  This
>> function (as well as `.Last' which is executed at the end of the R
>> session) can be defined in the appropriate startup profiles, or
>> reside in `.RData'.
>> 
>> as per R-intro, so the user has perfect control over what happens by
>> providing a suitable .First in e.g. his ~/.Rprofile.

> You are right -- I was discounting the "inelegant" use of an empty
> .First in .Rprofile to mask the one defined in the global environment.
> I have approached this in terms of preventing an unwanted package from
> being loaded, but I can see the advantages of using a .First
> definition in the user's .Rprofile to explicitly load packages as
> well.  I guess my worry would be that as the core of R gets smaller
> and more packages are added to the default list it would be simpler
> for the user to remove the one or two packages that are not wanted,
> rather than having to specify explicitly in a .First all the packages
> that are required, as would be the case currently.

Agreed.  Actually, I think that .First *is* the right mechanism for
taking care of this, but not necessarily though explicit coding.  What I
have in mind is something like

	R> customize()
or
	R> customize("packages")

(as opposed to customize("options"))

bringing up a mechanism through which packages can be selected.  (There
is an additional issue of specifying their order ...)  This could then
be saved into, say, a user or site R configuration file (R.ini, .Rini),
containing e.g.

	[Packages]
	ctest = TRUE
	ts = FALSE

etc (modulo order ...).  The startup mechanism could then look for such
a file and build .First-style code from it ...

-k
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] Detaching "ctest"
Kurt Hornik