[Rd] How to deal with package conflicts

[John Fox]

Hi Michael,

I'll look into moving survival to suggests (this weekend, if I have time),
but that doesn't address the more general issue.

Best,
 John

> -----Original Message-----
> From: Michael Friendly [mailto:friendly at yorku.ca]
> Sent: November-25-11 10:43 AM
> To: Terry Therneau
> Cc: r-devel at r-project.org; John Fox; Duncan Murdoch
> Subject: Re: [Rd] How to deal with package conflicts
> 
> On 11/25/2011 9:10 AM, Terry Therneau wrote:
> > The ridge() function was put into the survival package as a simple
> > example of what a user could do with penalized functions.  It's not a
> > "serious" function, and I'd be open to any suggestions for change.
> >
> > Actually, for any L2 penalty + Cox model one is now better off using
> > coxme as the maximization process is much better thought out there.
> > I'd be happy to remove ridge from survival -- except that there are
> > bound to be lots of folks using the function and any such changes
> > (even good
> > ones) to the survival package are fraught with peril.
> Duncan provided one suggestion:  make ridge() an S3 generic, and rename
> ridge()
> to ridge.coxph(), but this won't work, since you use ridge() inside
> coxph() and
> survreg() to add a penalty term in the model formula.
> Another idea might be simply to not export ridge(), but I have the
> feeling this will break your R CMD checks.
> 
> Alternatively, my particular problem (wanting to use car::vif in my
> package documentation) would be solved if John Fox considered making
> making survival a Suggests:
> package rather than a
> Depends: one.  This might work, since survival is only referenced in
> car by providing Anova() methods for coxph models.
> 
> I think all of this raises a general issue of unintended consequences
> of "package bloat," where
> (a) Depends: packages are forced to load by require()/library(),
> whether they are really needed or not;
> (b) There is nothing like require(car, depends=FALSE) to circumvent
> this;
> (c) Once a require()'d package is loaded, it cannot be unloaded;
> (d) AFAIK, there is no way for a package author to override the masking
> of functions or data provided by other other packages, except by using
> mypackage::myfun() calls.
> 
> To me this seems to be a flaw in the namespace mechanism.
> 
> best,
> -Michael
> 
> 
> 
> 
> 
> 
> 
> --
> Michael Friendly     Email: friendly AT yorku DOT ca
> Professor, Psychology Dept.
> York University      Voice: 416 736-5115 x66249 Fax: 416 736-5814
> 4700 Keele Street    Web:   http://www.datavis.ca
> Toronto, ONT  M3J 1P3 CANADA