[Rd] How to deal with package conflicts
jfox at mcmaster.ca
Mon Nov 28 00:57:29 CET 2011
As promised, I've moved survival to Suggests in the development version of
the car package on R-Forge. AFAICS, this doesn't cause any problems (and
should solve your problem).
I incidentally added Anova() and linearHypothesis() methods for svyglm
objects, and placed the survey package under Suggests.
> -----Original Message-----
> From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-
> project.org] On Behalf Of John Fox
> Sent: November-25-11 11:47 AM
> To: 'Michael Friendly'
> Cc: 'Terry Therneau'; r-devel at r-project.org
> Subject: Re: [Rd] How to deal with package conflicts
> 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.
> > -----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
> > >
> > > Actually, for any L2 penalty + Cox model one is now better off
> > > 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
> R-devel at r-project.org mailing list
More information about the R-devel