Imports problem

    > 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 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

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."