From edd at debian.org  Tue Feb 20 14:13:20 2007
From: edd at debian.org (Dirk Eddelbuettel)
Date: Tue, 20 Feb 2007 07:13:20 -0600
Subject: [Rd] Custom per-package options passed down via library() ?
In-Reply-To: <Pine.LNX.4.64.0702200736530.1875@gannet.stats.ox.ac.uk>
References: <17882.19097.558422.737418@basebud.nulle.part>
	<Pine.LNX.4.64.0702200736530.1875@gannet.stats.ox.ac.uk>
Message-ID: <17882.62448.646325.171009@basebud.nulle.part>


Dear Brian,

On 20 February 2007 at 07:46, Prof Brian Ripley wrote:
| Some packages have their own option-like mechanism, e.g. sm.
| Others use environment variables for this purpose.
| And there are userhooks for .First.lib, .onLoad and .onAttach that could 
| be exploited.

Ah, now I see setHook() et al. Interesting, thanks.  Won't help in my case --
I need to load a library without triggering some code branches, eg inits of
compiled code. I may just have to split my library, or do something else.
 
| In the Hmisc case, you are talking about messages, I believe.  You can 
| handle those via message classes.  The latter is not as easy as I would 
| like (and is currently under discussion), but in this particular case the 
| message class 'packageStartupMessage' of R >= 2.5.0 seems to be what is 
| wanted.
| 
| library() does not have a ... argument, so you cannot do what your subject 
| line suggests.  Since library() is scheduled to be replaced by use() 
| sometime Real Soon Now, it is not being enhanced but I think this is part 
| of the goals for use().

Interesting too -- that should be Real Useful Real Soon Now.

Thanks, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison



[Rd] Custom per-package options passed down via library() ?
Dirk Eddelbuettel