Thanks for the quick and clear responses. Indeed, I am not the maintainer of pkgB. And I figured that the solution lies in changes being made to pkgB. Hopefully the package author will be responsive.
Best, Wolfgang > -----Original Message----- > From: Prof Brian Ripley [mailto:rip...@stats.ox.ac.uk] > Sent: Sunday, September 28, 2014 15:23 > To: Duncan Murdoch; Viechtbauer Wolfgang (STAT); r-devel@r-project.org > Subject: Re: [Rd] Using requireNamespace() instead of require() > > On 28/09/2014 14:09, Duncan Murdoch wrote: > > On 28/09/2014, 8:47 AM, Viechtbauer Wolfgang (STAT) wrote: > >> Suppose I have a function funcA() in package pkgA that requires > function funcB() from another package pkgB under certain circumstances. > Those circumstances are rare though, so I put package pkgB under > 'Suggests', and use this in funcA() when those circumstances do arise: > >> > >> if (require("pkgB", quietly=TRUE)) { > >> pkgB::funcB(...) > >> } else { > >> stop("Please install package 'pkgB' to do this.") > >> } > >> > >> I understand that using requireNamespace() would be preferable and I > would also prefer to do that. But funcB() depends on funcC() from pkgC > that it lists under 'Depends'. So, with require("pkgB"), both namespaces > (of pkgB and pkgC) are loaded and attached to the search list and things > run. But with requireNamespace("pkgB"), only the namespace of pkgB is > loaded, so funcC() can't be found. So, I figured, I also use > requireNamespace("pkgC"), but that's not sufficient, since funcB() calls > funcC() and not pkgC::funcC(). > >> > >> Is there any solution to this? > > > > The solution needs to be implemented by the maintainer of pkgB. It > > probably doesn't really need pkgC on the search list, and could be > > modified to import funcC or explicitly call pkgC::funcC. > > > > If you aren't the maintainer of pkgB, and the real maintainer is > > unresponsive, then you're stuck using require(). > > I was writing something very similar, but added > > 'If the maintainer of pkgB does not respond you probably do not want to > rely on his work, not least because repository admins also will not get > a response from him.' > > > > > Duncan Murdoch > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford > 1 South Parks Road, Oxford OX1 3TG, UK ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
