On 16/02/2015 8:20 AM, Therneau, Terry M., Ph.D. wrote:> >> > I'm testing out a new version of coxme and R CMD check fails with "could not find function >> > ranef" (or random.effects or fixef, or anything from nlme). The NAMESPACE file has the >> > line below >> >> > importFrom(nlme, ranef, random.effects, fixef, fixed.effects, VarCorr) >> >> > and nlme is declared in the DESCRIPTION file as an import. I feel that I must be staring >> > at some obvious (but invisible to me) mistake. >> >> are you using them in (help page) examples, demos, or vignettes >> ? >> >> In that case, as you no longer 'Depend' on lme4, you need a >> require(lme4) >> before the corresponding code. > > Duncan and Martin, > > These are helpful comments. Let me start over and be more clear. It also helps that I'm > not writing this second note when I am too tired, and trying to push coxme out the door > before I had planned because of an interaction with one of the "survival" data sets > ("rats" got bigger, making one coxme test fail). > > 1. The heart of the issue is an attempt to follow the general advice of "almost no > depends, only imports." For the S3 methods imported from nlme I now see this as a bad > idea. The help page, vignettes, etc all tell the users of coxme to type "ranef(fit)" to > get random effects. I do not want to force them to type "nlme::ranef(fit)". I will > return nlme to the depends list.I believe you can import it and then export it from your own package, though I don't know if this will lead to other problems.> 2. I depend on the S3 generics of nlme: both of you wrote "lme4" in your response. > Freudian slip, or was there a reason?Not for me: I just copied it from Martin's message. I can include either, as long as it works. The> reason I don't define the generics myself is that it is quite possible for someone to be > fitting both linear and Cox mixed effects models, and if two packages define the generics > de novo then all methods for one of them disappear, or at least that was true in prior > releases of R (the last one loaded wins). Any advice? Take it as a given that survival > and coxme will remain firmly in the S3 camp. > > 3. Given 1 and 2, should the coxme function import all of nlme, or (as present) only the > methods?If you are depending on nlme, you don't need to also import it. But it is generally a good practice to avoid either modifying or relying on the search list: as people get more packages there, there are more chances for clashes. Duncan
On 16.02.2015 14:35, Duncan Murdoch wrote:> On 16/02/2015 8:20 AM, Therneau, Terry M., Ph.D. wrote: >> >>> > I'm testing out a new version of coxme and R CMD check fails with "could not find function >>> > ranef" (or random.effects or fixef, or anything from nlme). The NAMESPACE file has the >>> > line below >>> >>> > importFrom(nlme, ranef, random.effects, fixef, fixed.effects, VarCorr) >>> >>> > and nlme is declared in the DESCRIPTION file as an import. I feel that I must be staring >>> > at some obvious (but invisible to me) mistake. >>> >>> are you using them in (help page) examples, demos, or vignettes >>> ? >>> >>> In that case, as you no longer 'Depend' on lme4, you need a >>> require(lme4) >>> before the corresponding code. >> >> Duncan and Martin, >> >> These are helpful comments. Let me start over and be more clear. It also helps that I'm >> not writing this second note when I am too tired, and trying to push coxme out the door >> before I had planned because of an interaction with one of the "survival" data sets >> ("rats" got bigger, making one coxme test fail). >> >> 1. The heart of the issue is an attempt to follow the general advice of "almost no >> depends, only imports." For the S3 methods imported from nlme I now see this as a bad >> idea. The help page, vignettes, etc all tell the users of coxme to type "ranef(fit)" to >> get random effects. I do not want to force them to type "nlme::ranef(fit)". I will >> return nlme to the depends list. > > I believe you can import it and then export it from your own package, > though I don't know if this will lead to other problems. > >> 2. I depend on the S3 generics of nlme: both of you wrote "lme4" in your response. >> Freudian slip, or was there a reason? > > Not for me: I just copied it from Martin's message. > > I can include either, as long as it works. The >> reason I don't define the generics myself is that it is quite possible for someone to be >> fitting both linear and Cox mixed effects models, and if two packages define the generics >> de novo then all methods for one of them disappear, or at least that was true in prior >> releases of R (the last one loaded wins). Any advice? Take it as a given that survival >> and coxme will remain firmly in the S3 camp. >> >> 3. Given 1 and 2, should the coxme function import all of nlme, or (as present) only the >> methods? > > If you are depending on nlme, you don't need to also import it.Well, you should import all the functionality that you actually want to use (see Duncan's comment below). Otherwise R CMD check should yell. Best, Uwe> But it > is generally a good practice to avoid either modifying or relying on the > search list: as people get more packages there, there are more chances > for clashes. > > Duncan > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
On 02/16/2015 07:35 AM, Duncan Murdoch wrote:> If you are depending on nlme, you don't also need to import it. But it > is generally a good practice to avoid either modifying or relying on the > search list: as people get more packages there, there are more chances > for clashes.I would suggest adding the second sentence above to the "Writing R extensions" manual. At least for me, it made the :: argument much clearer in the following paragraph (found there). Before the "why" was a bit mysterious, now I have a motivation to make some of these changes in my own code. "R code in the package should call library or require only exceptionally. Such calls are never needed for packages listed in ?Depends? as they will already be on the search path. It used to be common practice to use require calls for packages listed in ?Suggests? in functions which used their functionality, but nowadays it is better to access such functionality via :: calls." I disagree with the above sentence in one case, however. That is in a vignette where one is showing the user a direction that they might go themselves. For example I'm currently working on a competing risks vignette for the survival package which shows how to do a particular analysis and then has a section on "if you choose to fit a Fine-Gray model instead, this is how it compares". Since any user who wanted to fit that model would themselves start with "library(cmprsk)", the vignette does so too. My argument is pedagogical rather than technical. Last note: your first sentence clashes with one in the Writing R extensions manual. "Almost always packages mentioned in ?Depends? should also be imported from in the NAMESPACE file: this ensures that any needed parts of those packages are available when some other package imports the current package."