Re: [Rd] Re R CMD check checking in development version of R
And if, like me, you always forget which of Depends and Imports is the one you are supposed to be using, the mnemonic device is "DEPends is DEPrecated[1], IMPorts is IMPortant." Barry [1] kinda. On Thu, Aug 28, 2014 at 4:33 AM, Gavin Simpson wrote: > On Aug 27, 2014 5:24 PM, "Hadley Wickham" > >> I'd say: Depends is a historical artefact from ye old days before >> package namespaces. Apart from depending on a specific version of R, >> you should basically never use depends. (The one exception is, as >> mentioned in R-exts, if you're writing something like latticeExtras >> that doesn't make sense unless lattice is already loaded). > > Keeping this nuance in mind when when discussing Depends vs Imports is > important so as to not suggest that there isn't any reason to use Depends > any longer. > > I am in full agreement that its use should be limited to exceptional > situations, and have modified my packages accordingly. > > Cheers, > > G > >> > This check (whilst having found some things I should have imported and >> > didn't - which is a good thing!) seems to be circumventing the > intention of >> > having something in Depends. Is Depends going to go away? >> >> I don't think it's going to go away anytime soon, but you should >> consider it to be largely deprecated and you should avoid it wherever >> possible. >> >> >> (And really you shouldn't have any packages in depends, they should >> >> all be in imports) >> > >> > I disagree with *any*; having say vegan loaded when one is using > analogue is >> > a design decision as the latter borrows heavily from and builds upon > vegan. >> > In general I have moved packages that didn't need to be in Depends into >> > Imports; in the version I am currently doing final tweaks on before it > goes >> > to CRAN I have remove all but vegan from Depends. >> >> I think that is a reasonable use case for depends. Here's the exact >> text from R-exts: "Field ‘Depends’ should nowadays be used rarely, >> only for packages which are intended to be put on the search path to >> make their facilities available to the end user (and not to the >> package itself): for example it makes sense that a user of package >> latticeExtra would want the functions of package lattice made >> available." >> >> Personally I avoid even this use, requiring users of my packages to be >> explicit about exactly what packages are on the search path. You are >> of course welcome to your own approach, but I think you'll find it >> will become more and more difficult to maintain in time. I recommend >> that you bite the bullet now. >> >> Put another way, packages should be extremely conservative about >> global side effects (and modifying the search path is such a >> side-effect) >> >> Hadley >> >> -- >> http://had.co.nz/ > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] no visible binding for global variable for data sets in a package
> peter dalgaard
> on Wed, 27 Aug 2014 21:09:47 +0200 writes:
> On 27 Aug 2014, at 16:48 , Hadley Wickham wrote:
>>> I think the right answer _is_ to export the lazy data; the question is
how to do it. There's nothing particularly strange about exporting
non-functions ("letters" would be an example, save for the special status of
package:base). If you attach the package, the lazyloaded data appear in the
same environment as the exported function so they are de facto already in the
namespace for the purposes of library() and `::`. So I agree, something like
exportData() would be useful. (Or some other mechanism. You might want to be
able to export data selectively.)
>>
>> I don't think lazyloaded data are in the same environment as exported
>> functions - getExportedValue() (called by ::) looks first in the
>> "exports" namespace, then in the "lazydata" namespace:
>>
>> function (ns, name)
>> {
>> getInternalExportName <- function(name, ns) {
>> exports <- getNamespaceInfo(ns, "exports")
>> if (exists(name, envir = exports, inherits = FALSE))
>> get(get(name, envir = exports, inherits = FALSE),
>> envir = ns)
>> else {
>> ld <- getNamespaceInfo(ns, "lazydata")
>> if (exists(name, envir = ld, inherits = FALSE))
>> get(name, envir = ld, inherits = FALSE)
>> else stop(gettextf("'%s' is not an exported object from
>> 'namespace:%s'",
>> name, getNamespaceName(ns)), call. = FALSE, domain = NA)
>> }
>> }
>> ns <- asNamespace(ns)
>> if (isBaseNamespace(ns))
>> get(name, envir = ns, inherits = FALSE)
>> else getInternalExportName(name, ns)
>> }
>>
>>
>> (But maybe you just meant the library() and :: behaves as is lazydata
>> and exports were the same thing)
>>
>> Hadley
>>
>> --
>> http://had.co.nz/
> I meant that
> a) :: gives results as if the data was in the namespace
> b) if you do
>> library(MASS)
>> ls("package:MASS")
> [1] "abbey" "accdeaths" "addterm"
> [4] "Aids2" "Animals""anorexia"
> [7] "area" "as.fractions" "bacteria"
> [10] "bandwidth.nrd" "bcv""beav1"
>
> data and functions get put together in the same environment (however,
this is not the namespace environment, see later).
> What puzzles me is why the distinction between lazydata and exports was
there to begin with.
> The implication of the current setup is clearly that pkg::foo() cannot
access package::dat by referring to `dat` whereas it can do so if invoked as
library(pkg); foo().
> We also have
>> get("accdeaths", environment(MASS::addterm))
> Error in get("accdeaths", environment(MASS::addterm)) :
> object 'accdeaths' not found
>> library(MASS)
>> get("accdeaths", environment(MASS::addterm))
> Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov
> 1973 9007 8106 8928 9137 10017 10826 11317 10744 9713 9938 9161
> 1974 7750 6981 8038 8422 8714 9512 10120 9823 8743 9129 8710
> ...
> which confused me at first, but it actually just means that "accdeaths"
is found on the search path in the latter case. This strikes me as somewhat
dangerous: If a package uses one of its own datasets, it can be masked by a
later attach() or the global env.
> (I suspect that someone already explained all this a while back, but I
just wasn't listening at the time...)
I did say (as first reply in this thread) that the lazyloaded
datasets where in the package environment, but not
in the package's *namespace* environment -- which is somewhat
exceptional, as otherwise, the namespace envir is typically a superset
of the package envir, and I did mention the solution with
sysdata.rda + NAMESPACE which Brian and Hadley later mentioned, too.
However Michael did not get it well enough (because you
need to read other material), and I do think that is not an
ideal solution for data sets that have help pages, etc; notably
because creating sysdata.rda is not at all part of the package
sources, and hence harder for maintenance and "open source transparency".
The one additional important in the thread was the special
semantic of '::' which here returns something for
:: which is *not* part of the 's namespace,
whereas the use of '::' does suggest to Joe Average to be
working with namespace (as opposed to package) contents.
I agree with your suggestion, Peter, that this looks more
confusing than it should, and ideally, we'd find a better setup.
OTOH, if we additionally allowed something like exportData(),
we would additionally get data that is both in the package and
namespace environments and other (not exported) data that is
only in the package, so add room for even more confusion.
Martin
__
Re: [Rd] Re R CMD check checking in development version of R
On 08/27/2014 08:33 PM, Gavin Simpson wrote: On Aug 27, 2014 5:24 PM, "Hadley Wickham" I'd say: Depends is a historical artefact from ye old days before package namespaces. Apart from depending on a specific version of R, you should basically never use depends. (The one exception is, as mentioned in R-exts, if you're writing something like latticeExtras that doesn't make sense unless lattice is already loaded). Keeping this nuance in mind when when discussing Depends vs Imports is important so as to not suggest that there isn't any reason to use Depends any longer. A common case in Bioconductor is that a package defines a class and methods intended for the user; this requires the package to be on the search path (else the user wouldn't be able to do anything with the returned object). A class and supporting methods can represent significant infrastructure, so that it makes sense to separate these in distinct packages. It is not uncommon to find 3-5 or more packages in the Depends: field of derived packages for this reason. Martin I am in full agreement that its use should be limited to exceptional situations, and have modified my packages accordingly. Cheers, G This check (whilst having found some things I should have imported and didn't - which is a good thing!) seems to be circumventing the intention of having something in Depends. Is Depends going to go away? I don't think it's going to go away anytime soon, but you should consider it to be largely deprecated and you should avoid it wherever possible. (And really you shouldn't have any packages in depends, they should all be in imports) I disagree with *any*; having say vegan loaded when one is using analogue is a design decision as the latter borrows heavily from and builds upon vegan. In general I have moved packages that didn't need to be in Depends into Imports; in the version I am currently doing final tweaks on before it goes to CRAN I have remove all but vegan from Depends. I think that is a reasonable use case for depends. Here's the exact text from R-exts: "Field ‘Depends’ should nowadays be used rarely, only for packages which are intended to be put on the search path to make their facilities available to the end user (and not to the package itself): for example it makes sense that a user of package latticeExtra would want the functions of package lattice made available." Personally I avoid even this use, requiring users of my packages to be explicit about exactly what packages are on the search path. You are of course welcome to your own approach, but I think you'll find it will become more and more difficult to maintain in time. I recommend that you bite the bullet now. Put another way, packages should be extremely conservative about global side effects (and modifying the search path is such a side-effect) Hadley -- http://had.co.nz/ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
>>> I'd say: Depends is a historical artefact from ye old days before >>> package namespaces. Apart from depending on a specific version of R, >>> you should basically never use depends. (The one exception is, as >>> mentioned in R-exts, if you're writing something like latticeExtras >>> that doesn't make sense unless lattice is already loaded). >> >> Keeping this nuance in mind when when discussing Depends vs Imports is >> important so as to not suggest that there isn't any reason to use Depends >> any longer. > > A common case in Bioconductor is that a package defines a class and methods > intended for the user; this requires the package to be on the search path > (else the user wouldn't be able to do anything with the returned object). A > class and supporting methods can represent significant infrastructure, so > that it makes sense to separate these in distinct packages. It is not > uncommon to find 3-5 or more packages in the Depends: field of derived > packages for this reason. For that scenario, is it reasonable to say that every package in depends must also be in imports? Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
On 08/28/2014 05:52 AM, Hadley Wickham wrote: I'd say: Depends is a historical artefact from ye old days before package namespaces. Apart from depending on a specific version of R, you should basically never use depends. (The one exception is, as mentioned in R-exts, if you're writing something like latticeExtras that doesn't make sense unless lattice is already loaded). Keeping this nuance in mind when when discussing Depends vs Imports is important so as to not suggest that there isn't any reason to use Depends any longer. A common case in Bioconductor is that a package defines a class and methods intended for the user; this requires the package to be on the search path (else the user wouldn't be able to do anything with the returned object). A class and supporting methods can represent significant infrastructure, so that it makes sense to separate these in distinct packages. It is not uncommon to find 3-5 or more packages in the Depends: field of derived packages for this reason. For that scenario, is it reasonable to say that every package in depends must also be in imports? Important to pay attention to capitalization here. A package listed in Depends: _never_ needs to be listed in Imports:, but will often be import()'ed (in one way or another) in the NAMESPACE. Some would argue that listing a package in Depends: and Imports: in this case clarifies intent -- provides functionality available to the user, and important for the package itself. Others (such as R CMD check) view the replication as redundancy. I think one can imagine scenarios where a package in the Depends: fields does not actually have anything import()'ed, e.g., PkgA defines a class, PkgB provides some special functionality that returns the class PkgC use PkgB's special functionality without ever manipulating the object of PkgA. Martin Morgan Hadley -- Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M1 B861 Phone: (206) 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] no visible binding for global variable for data sets in a package
Here is one rationale for the change, which was useful for my understanding This arises in the survival package in the survexp function: survexp <- function(formula, data, weights, subset, na.action, ratetable=survexp.us) The argument has been changed to survival::survexp.us, soon to be uploaded to CRAN. Assume that a user has an object named "survexp.us" in their working data, and calls survexp without providing a ratetable arguement. Should they get the package default or their own object? I'd vote for the first, but the current behavior is the latter. This was presented to me as "fixing a bug that has long been present, but we never noticed before." Now, if the user adds "ratetable=survexp.us" to the call they should get their own object. I've always hated computer systems that ignore explicit direction, assuming they know more than me. Terry Therneau __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > On 27 August 2014 15:24, Hadley Wickham wrote: > >>> Is that the cause of these NOTEs? Is the expectation that if I am using a >>> function from a package, even a package that I have in Depends:, that I >>> have to explicitly declare these imports in NAMESPACE? >> >> Yes. >> >> (Otherwise your package won't work if it's only attached and not >> loaded. i.e. if someone does analogue::foo() only the imported >> functions are available, not the functions in packages you depend on) >> > > Cheers Hadley. Thanks for the confirmation, but... > > ...I don't get this; what is the point of Depends? I thought it was "my > package needs these other packages to work, i.e. be loaded". Hence it is > user error (IMHO ;-) to do `analogue::foo()` without having the > dependencies loaded too. > No. The point of Depends is that if your package is attached, it also attaches the other packages to make them available for the user. Essentially you're saying "if you want to use my package interactively, you will also want to use those other packages interactively". You still need to use import() to define what exactly is used by your package - as opposed to what you want to be available to the user in case it is attached. Cheers, Simon > This check (whilst having found some things I should have imported and > didn't - which is a good thing!) seems to be circumventing the intention of > having something in Depends. Is Depends going to go away? > > >> (And really you shouldn't have any packages in depends, they should >> all be in imports) > > > I disagree with *any*; having say vegan loaded when one is using analogue > is a design decision as the latter borrows heavily from and builds upon > vegan. In general I have moved packages that didn't need to be in Depends > into Imports; in the version I am currently doing final tweaks on before it > goes to CRAN I have remove all but vegan from Depends. > > Or am I thinking about this in the wrong way? > > Thanks again > > Gavin > > >> >> Hadley >> >> >> -- >> http://had.co.nz/ >> > > > > -- > Gavin Simpson, PhD > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
This is a nice explanation of the Imports/Depends distinction. It ought to go into the Extensions ref manual imho. Cheers, Bert Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 "Data is not information. Information is not knowledge. And knowledge is certainly not wisdom." Clifford Stoll On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek wrote: > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > >> On 27 August 2014 15:24, Hadley Wickham wrote: >> Is that the cause of these NOTEs? Is the expectation that if I am using a function from a package, even a package that I have in Depends:, that I have to explicitly declare these imports in NAMESPACE? >>> >>> Yes. >>> >>> (Otherwise your package won't work if it's only attached and not >>> loaded. i.e. if someone does analogue::foo() only the imported >>> functions are available, not the functions in packages you depend on) >>> >> >> Cheers Hadley. Thanks for the confirmation, but... >> >> ...I don't get this; what is the point of Depends? I thought it was "my >> package needs these other packages to work, i.e. be loaded". Hence it is >> user error (IMHO ;-) to do `analogue::foo()` without having the >> dependencies loaded too. >> > > No. The point of Depends is that if your package is attached, it also > attaches the other packages to make them available for the user. Essentially > you're saying "if you want to use my package interactively, you will also > want to use those other packages interactively". You still need to use > import() to define what exactly is used by your package - as opposed to what > you want to be available to the user in case it is attached. > > Cheers, > Simon > > > >> This check (whilst having found some things I should have imported and >> didn't - which is a good thing!) seems to be circumventing the intention of >> having something in Depends. Is Depends going to go away? >> >> >>> (And really you shouldn't have any packages in depends, they should >>> all be in imports) >> >> >> I disagree with *any*; having say vegan loaded when one is using analogue >> is a design decision as the latter borrows heavily from and builds upon >> vegan. In general I have moved packages that didn't need to be in Depends >> into Imports; in the version I am currently doing final tweaks on before it >> goes to CRAN I have remove all but vegan from Depends. >> >> Or am I thinking about this in the wrong way? >> >> Thanks again >> >> Gavin >> >> >>> >>> Hadley >>> >>> >>> -- >>> http://had.co.nz/ >>> >> >> >> >> -- >> Gavin Simpson, PhD >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
Hi, I second Bert's comment. I would like to go even farther and suggest that it would be really useful if one of the R gurus (like Simon) wrote a relatively non-technical article in the R journal on this topic of "Depends/Imports/Suggested." Someone like myself would benefit immensely. Thank you, Ravi -Original Message- From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On Behalf Of Bert Gunter Sent: Thursday, August 28, 2014 10:47 AM To: Simon Urbanek Cc: r-devel@r-project.org Subject: Re: [Rd] Re R CMD check checking in development version of R This is a nice explanation of the Imports/Depends distinction. It ought to go into the Extensions ref manual imho. Cheers, Bert Bert Gunter Genentech Nonclinical Biostatistics (650) 467-7374 "Data is not information. Information is not knowledge. And knowledge is certainly not wisdom." Clifford Stoll On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek wrote: > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > >> On 27 August 2014 15:24, Hadley Wickham wrote: >> Is that the cause of these NOTEs? Is the expectation that if I am using a function from a package, even a package that I have in Depends:, that I have to explicitly declare these imports in NAMESPACE? >>> >>> Yes. >>> >>> (Otherwise your package won't work if it's only attached and not >>> loaded. i.e. if someone does analogue::foo() only the imported >>> functions are available, not the functions in packages you depend >>> on) >>> >> >> Cheers Hadley. Thanks for the confirmation, but... >> >> ...I don't get this; what is the point of Depends? I thought it was >> "my package needs these other packages to work, i.e. be loaded". >> Hence it is user error (IMHO ;-) to do `analogue::foo()` without >> having the dependencies loaded too. >> > > No. The point of Depends is that if your package is attached, it also > attaches the other packages to make them available for the user. Essentially > you're saying "if you want to use my package interactively, you will also > want to use those other packages interactively". You still need to use > import() to define what exactly is used by your package - as opposed to what > you want to be available to the user in case it is attached. > > Cheers, > Simon > > > >> This check (whilst having found some things I should have imported >> and didn't - which is a good thing!) seems to be circumventing the >> intention of having something in Depends. Is Depends going to go away? >> >> >>> (And really you shouldn't have any packages in depends, they should >>> all be in imports) >> >> >> I disagree with *any*; having say vegan loaded when one is using >> analogue is a design decision as the latter borrows heavily from and >> builds upon vegan. In general I have moved packages that didn't need >> to be in Depends into Imports; in the version I am currently doing >> final tweaks on before it goes to CRAN I have remove all but vegan from >> Depends. >> >> Or am I thinking about this in the wrong way? >> >> Thanks again >> >> Gavin >> >> >>> >>> Hadley >>> >>> >>> -- >>> http://had.co.nz/ >>> >> >> >> >> -- >> Gavin Simpson, PhD >> >> [[alternative HTML version deleted]] >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
>From a developers point of view, these days a less ambiguous name for 'Depends' would be 'Attaches'. ...or maybe even 'ImportsAndAttaches' with 'ImportsOnly' (for 'Imports'). I think Simon phrased it very well, and as others already pointed out, having one package attaching additional ones certainly has its values. This is probably more useful for packages that are used directly by the end user than for packages that mainly provides infrastructure to other packages. Henrik On Aug 28, 2014 7:48 AM, "Bert Gunter" wrote: > This is a nice explanation of the Imports/Depends distinction. It > ought to go into the Extensions ref manual imho. > > Cheers, > Bert > > Bert Gunter > Genentech Nonclinical Biostatistics > (650) 467-7374 > > "Data is not information. Information is not knowledge. And knowledge > is certainly not wisdom." > Clifford Stoll > > > > > On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek > wrote: > > > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > > > >> On 27 August 2014 15:24, Hadley Wickham wrote: > >> > Is that the cause of these NOTEs? Is the expectation that if I am > using a > function from a package, even a package that I have in Depends:, that > I > have to explicitly declare these imports in NAMESPACE? > >>> > >>> Yes. > >>> > >>> (Otherwise your package won't work if it's only attached and not > >>> loaded. i.e. if someone does analogue::foo() only the imported > >>> functions are available, not the functions in packages you depend on) > >>> > >> > >> Cheers Hadley. Thanks for the confirmation, but... > >> > >> ...I don't get this; what is the point of Depends? I thought it was "my > >> package needs these other packages to work, i.e. be loaded". Hence it is > >> user error (IMHO ;-) to do `analogue::foo()` without having the > >> dependencies loaded too. > >> > > > > No. The point of Depends is that if your package is attached, it also > attaches the other packages to make them available for the user. > Essentially you're saying "if you want to use my package interactively, you > will also want to use those other packages interactively". You still need > to use import() to define what exactly is used by your package - as opposed > to what you want to be available to the user in case it is attached. > > > > Cheers, > > Simon > > > > > > > >> This check (whilst having found some things I should have imported and > >> didn't - which is a good thing!) seems to be circumventing the > intention of > >> having something in Depends. Is Depends going to go away? > >> > >> > >>> (And really you shouldn't have any packages in depends, they should > >>> all be in imports) > >> > >> > >> I disagree with *any*; having say vegan loaded when one is using > analogue > >> is a design decision as the latter borrows heavily from and builds upon > >> vegan. In general I have moved packages that didn't need to be in > Depends > >> into Imports; in the version I am currently doing final tweaks on > before it > >> goes to CRAN I have remove all but vegan from Depends. > >> > >> Or am I thinking about this in the wrong way? > >> > >> Thanks again > >> > >> Gavin > >> > >> > >>> > >>> Hadley > >>> > >>> > >>> -- > >>> http://had.co.nz/ > >>> > >> > >> > >> > >> -- > >> Gavin Simpson, PhD > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
I fully agree. This is how I have come to understand Depends vs Imports and why I currently will not be removing vegan from Depends for my analogue package. This is also why I was pushing back against the notion that was voiced early in this thread that *nothing* should be in Depends. Cheers G On 28 August 2014 08:47, Bert Gunter wrote: > This is a nice explanation of the Imports/Depends distinction. It > ought to go into the Extensions ref manual imho. > > Cheers, > Bert > > Bert Gunter > Genentech Nonclinical Biostatistics > (650) 467-7374 > > "Data is not information. Information is not knowledge. And knowledge > is certainly not wisdom." > Clifford Stoll > > > > > On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek > wrote: > > > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > > > >> On 27 August 2014 15:24, Hadley Wickham wrote: > >> > Is that the cause of these NOTEs? Is the expectation that if I am > using a > function from a package, even a package that I have in Depends:, that > I > have to explicitly declare these imports in NAMESPACE? > >>> > >>> Yes. > >>> > >>> (Otherwise your package won't work if it's only attached and not > >>> loaded. i.e. if someone does analogue::foo() only the imported > >>> functions are available, not the functions in packages you depend on) > >>> > >> > >> Cheers Hadley. Thanks for the confirmation, but... > >> > >> ...I don't get this; what is the point of Depends? I thought it was "my > >> package needs these other packages to work, i.e. be loaded". Hence it is > >> user error (IMHO ;-) to do `analogue::foo()` without having the > >> dependencies loaded too. > >> > > > > No. The point of Depends is that if your package is attached, it also > attaches the other packages to make them available for the user. > Essentially you're saying "if you want to use my package interactively, you > will also want to use those other packages interactively". You still need > to use import() to define what exactly is used by your package - as opposed > to what you want to be available to the user in case it is attached. > > > > Cheers, > > Simon > > > > > > > >> This check (whilst having found some things I should have imported and > >> didn't - which is a good thing!) seems to be circumventing the > intention of > >> having something in Depends. Is Depends going to go away? > >> > >> > >>> (And really you shouldn't have any packages in depends, they should > >>> all be in imports) > >> > >> > >> I disagree with *any*; having say vegan loaded when one is using > analogue > >> is a design decision as the latter borrows heavily from and builds upon > >> vegan. In general I have moved packages that didn't need to be in > Depends > >> into Imports; in the version I am currently doing final tweaks on > before it > >> goes to CRAN I have remove all but vegan from Depends. > >> > >> Or am I thinking about this in the wrong way? > >> > >> Thanks again > >> > >> Gavin > >> > >> > >>> > >>> Hadley > >>> > >>> > >>> -- > >>> http://had.co.nz/ > >>> > >> > >> > >> > >> -- > >> Gavin Simpson, PhD > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > > > > __ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gavin Simpson, PhD [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
Gavin, I admit to not knowing the details of your package, but do users commonly need to use symbols from other package *in calls to functions exported by your package*? If so, you're in the situation Martin (Morgan) described, which is one I think everyone agrees Depends is appropriate for. If the above is not the case, and you're arguing it's simply convenient for users because it's very common for them to use top level functions from both in the same analysis, the case for Depends is not as strong. In that case, the official wisdom, AFAIK, is that Depends is not warranted. ~G On Thu, Aug 28, 2014 at 11:43 AM, Gavin Simpson wrote: > I fully agree. > > This is how I have come to understand Depends vs Imports and why I > currently will not be removing vegan from Depends for my analogue package. > This is also why I was pushing back against the notion that was voiced > early in this thread that *nothing* should be in Depends. > > Cheers > > G > > > On 28 August 2014 08:47, Bert Gunter wrote: > > > This is a nice explanation of the Imports/Depends distinction. It > > ought to go into the Extensions ref manual imho. > > > > Cheers, > > Bert > > > > Bert Gunter > > Genentech Nonclinical Biostatistics > > (650) 467-7374 > > > > "Data is not information. Information is not knowledge. And knowledge > > is certainly not wisdom." > > Clifford Stoll > > > > > > > > > > On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek > > wrote: > > > > > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: > > > > > >> On 27 August 2014 15:24, Hadley Wickham wrote: > > >> > > Is that the cause of these NOTEs? Is the expectation that if I am > > using a > > function from a package, even a package that I have in Depends:, > that > > I > > have to explicitly declare these imports in NAMESPACE? > > >>> > > >>> Yes. > > >>> > > >>> (Otherwise your package won't work if it's only attached and not > > >>> loaded. i.e. if someone does analogue::foo() only the imported > > >>> functions are available, not the functions in packages you depend on) > > >>> > > >> > > >> Cheers Hadley. Thanks for the confirmation, but... > > >> > > >> ...I don't get this; what is the point of Depends? I thought it was > "my > > >> package needs these other packages to work, i.e. be loaded". Hence it > is > > >> user error (IMHO ;-) to do `analogue::foo()` without having the > > >> dependencies loaded too. > > >> > > > > > > No. The point of Depends is that if your package is attached, it also > > attaches the other packages to make them available for the user. > > Essentially you're saying "if you want to use my package interactively, > you > > will also want to use those other packages interactively". You still need > > to use import() to define what exactly is used by your package - as > opposed > > to what you want to be available to the user in case it is attached. > > > > > > Cheers, > > > Simon > > > > > > > > > > > >> This check (whilst having found some things I should have imported and > > >> didn't - which is a good thing!) seems to be circumventing the > > intention of > > >> having something in Depends. Is Depends going to go away? > > >> > > >> > > >>> (And really you shouldn't have any packages in depends, they should > > >>> all be in imports) > > >> > > >> > > >> I disagree with *any*; having say vegan loaded when one is using > > analogue > > >> is a design decision as the latter borrows heavily from and builds > upon > > >> vegan. In general I have moved packages that didn't need to be in > > Depends > > >> into Imports; in the version I am currently doing final tweaks on > > before it > > >> goes to CRAN I have remove all but vegan from Depends. > > >> > > >> Or am I thinking about this in the wrong way? > > >> > > >> Thanks again > > >> > > >> Gavin > > >> > > >> > > >>> > > >>> Hadley > > >>> > > >>> > > >>> -- > > >>> http://had.co.nz/ > > >>> > > >> > > >> > > >> > > >> -- > > >> Gavin Simpson, PhD > > >> > > >> [[alternative HTML version deleted]] > > >> > > >> __ > > >> R-devel@r-project.org mailing list > > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > >> > > > > > > __ > > > R-devel@r-project.org mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > -- > Gavin Simpson, PhD > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabriel Becker Graduate Student Statistics Department University of California, Davis [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re R CMD check checking in development version of R
Gabriel, That is not my understanding of this at all. I could hide the fact that I was using vegan under the hood, supplying methods for its generics and by exporting the generic I imported from vegan, etc. But you are missing the point that I see users of my package, because I envisioned close interlinking with the functionality provided by vegan, wanting to use vegan interactively with many of the objects that functions in analogue create. I do feel this aversion to Depends is being taken too far by some. Simon's articulation in this thread of what Depends means (to him) is the closest I have seen to how I have interpreted things. That's also about as close to official wisdom that I have seen beyond what is in Writing R Extensions. Analogue also uses Lattice, but I have moved this to Imports as I don't expect users to be manipulating the few plot alternatives analogue provides using this graphics package and if they want to they can load lattice themselves. So, I fully understand the differences and nuances of Depends and Imports etc. I just don't agree with those that claim no packages should be in Depends, or that my use case is somehow wrong or not best practice. G On 28 August 2014 15:14, Gabriel Becker wrote: > Gavin, > > I admit to not knowing the details of your package, but do users commonly > need to use symbols from other package *in calls to functions exported by > your package*? If so, you're in the situation Martin (Morgan) described, > which is one I think everyone agrees Depends is appropriate for. > > If the above is not the case, and you're arguing it's simply convenient > for users because it's very common for them to use top level functions from > both in the same analysis, the case for Depends is not as strong. In that > case, the official wisdom, AFAIK, is that Depends is not warranted. > > ~G > > > On Thu, Aug 28, 2014 at 11:43 AM, Gavin Simpson wrote: > >> I fully agree. >> >> This is how I have come to understand Depends vs Imports and why I >> currently will not be removing vegan from Depends for my analogue package. >> This is also why I was pushing back against the notion that was voiced >> early in this thread that *nothing* should be in Depends. >> >> Cheers >> >> G >> >> >> On 28 August 2014 08:47, Bert Gunter wrote: >> >> > This is a nice explanation of the Imports/Depends distinction. It >> > ought to go into the Extensions ref manual imho. >> > >> > Cheers, >> > Bert >> > >> > Bert Gunter >> > Genentech Nonclinical Biostatistics >> > (650) 467-7374 >> > >> > "Data is not information. Information is not knowledge. And knowledge >> > is certainly not wisdom." >> > Clifford Stoll >> > >> > >> > >> > >> > On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek >> > wrote: >> > > >> > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: >> > > >> > >> On 27 August 2014 15:24, Hadley Wickham wrote: >> > >> >> > Is that the cause of these NOTEs? Is the expectation that if I am >> > using a >> > function from a package, even a package that I have in Depends:, >> that >> > I >> > have to explicitly declare these imports in NAMESPACE? >> > >>> >> > >>> Yes. >> > >>> >> > >>> (Otherwise your package won't work if it's only attached and not >> > >>> loaded. i.e. if someone does analogue::foo() only the imported >> > >>> functions are available, not the functions in packages you depend >> on) >> > >>> >> > >> >> > >> Cheers Hadley. Thanks for the confirmation, but... >> > >> >> > >> ...I don't get this; what is the point of Depends? I thought it was >> "my >> > >> package needs these other packages to work, i.e. be loaded". Hence >> it is >> > >> user error (IMHO ;-) to do `analogue::foo()` without having the >> > >> dependencies loaded too. >> > >> >> > > >> > > No. The point of Depends is that if your package is attached, it also >> > attaches the other packages to make them available for the user. >> > Essentially you're saying "if you want to use my package interactively, >> you >> > will also want to use those other packages interactively". You still >> need >> > to use import() to define what exactly is used by your package - as >> opposed >> > to what you want to be available to the user in case it is attached. >> > > >> > > Cheers, >> > > Simon >> > > >> > > >> > > >> > >> This check (whilst having found some things I should have imported >> and >> > >> didn't - which is a good thing!) seems to be circumventing the >> > intention of >> > >> having something in Depends. Is Depends going to go away? >> > >> >> > >> >> > >>> (And really you shouldn't have any packages in depends, they should >> > >>> all be in imports) >> > >> >> > >> >> > >> I disagree with *any*; having say vegan loaded when one is using >> > analogue >> > >> is a design decision as the latter borrows heavily from and builds >> upon >> > >> vegan. In general I have moved packages that didn't need to be in >> > Depends >> > >> into Imports; in the version I am currently doing final tweaks on >>
Re: [Rd] Re R CMD check checking in development version of R
Gavin, I don't claim to be the arbiter of good package design. The following are my opinions, along with the reasons I hold them. If you are also importing vegan, which I think everyone agreed needs to happen, the only thing putting vegan in Depends does is attach the package. This is something users can easily do themselves, and which *may* not be required to use your package (I don't know). As such, using Depends limits the user's agency/control over their session in return for what I would argue may (depending on circumstance) be a nominal benefit at best. Continued inline. On Thu, Aug 28, 2014 at 2:42 PM, Gavin Simpson wrote: > Gabriel, > > That is not my understanding of this at all. I could hide the fact that I > was using vegan under the hood, supplying methods for its generics and by > exporting the generic I imported from vegan, etc. But you are missing the > point that I see users of my package, because I envisioned close > interlinking with the functionality provided by vegan, wanting to use vegan > interactively with many of the objects that functions in analogue create. > Well sure, but if that is the case, they know they want to call functions in vegan, so I would think that they would expect to load vegan and not really think twice about having to do so, making your Depends irrelevant. The other question is, can analogue be used without vegan? If it can, *forcing* users to have vegan attached it doesn't seem desirable. Depends gives users less power to avoid or resolve symbol conflicts. Point in case, there is a logging package called log4r which overrides the 'debug' (madness, I know) symbol, and I once had a package (call it PkgA) loaded which Depends on log4r it, with good reason, even, since you are expected to pass a user-created logging object of some kind to the to PkgA's functions. This meant that the base-R debug function was *mandatorally* masked. This is very bad for the user (me), and honestly if the author hadn't agreed to change the Dependency I wouldn't even consider using the package. If log4r has been imported, I wouldn't have cared at all, as I would have been in control of whether the package was attached or not, and when. I'm sure (hope) that vegan doesn't do anything this egregious, and if not, your use of Depends isn't The-Most-Horrible-Thing-Ever. I'd argue that it is undesirable, but relatively mildly so, and others may argue not at all. > > I do feel this aversion to Depends is being taken too far by some. Simon's > articulation in this thread of what Depends means (to him) is the closest I > have seen to how I have interpreted things. That's also about as close to > official wisdom that I have seen beyond what is in Writing R Extensions. > If the official wisdom from R-core disagrees with me, that is probably a good reason not to listen to me. I was under the impression that Depends was not recommended except in cases like the described by Mr. Morgan. Best, ~G On 28 August 2014 15:14, Gabriel Becker wrote: > Gavin, > > I admit to not knowing the details of your package, but do users commonly > need to use symbols from other package *in calls to functions exported by > your package*? If so, you're in the situation Martin (Morgan) described, > which is one I think everyone agrees Depends is appropriate for. > > If the above is not the case, and you're arguing it's simply convenient > for users because it's very common for them to use top level functions from > both in the same analysis, the case for Depends is not as strong. In that > case, the official wisdom, AFAIK, is that Depends is not warranted. > > ~G > > > On Thu, Aug 28, 2014 at 11:43 AM, Gavin Simpson wrote: > >> I fully agree. >> >> This is how I have come to understand Depends vs Imports and why I >> currently will not be removing vegan from Depends for my analogue package. >> This is also why I was pushing back against the notion that was voiced >> early in this thread that *nothing* should be in Depends. >> >> Cheers >> >> G >> >> >> On 28 August 2014 08:47, Bert Gunter wrote: >> >> > This is a nice explanation of the Imports/Depends distinction. It >> > ought to go into the Extensions ref manual imho. >> > >> > Cheers, >> > Bert >> > >> > Bert Gunter >> > Genentech Nonclinical Biostatistics >> > (650) 467-7374 >> > >> > "Data is not information. Information is not knowledge. And knowledge >> > is certainly not wisdom." >> > Clifford Stoll >> > >> > >> > >> > >> > On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek >> > wrote: >> > > >> > > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: >> > > >> > >> On 27 August 2014 15:24, Hadley Wickham wrote: >> > >> >> > Is that the cause of these NOTEs? Is the expectation that if I am >> > using a >> > function from a package, even a package that I have in Depends:, >> that >> > I >> > have to explicitly declare these imports in NAMESPACE? >> > >>> >> > >>> Yes. >> > >>> >> > >>> (Otherwise your package won't work if it's only
Re: [Rd] Re R CMD check checking in development version of R
Yes, Depends certainly has a role. The ability of one package to automatically provide all the facilities of another package to the user is important. There are many situations where the functionality you want to provide to the user is split among multiple packages. For example, 1. xts uses zoo and the user ought to be able to use all the functionality of zoo when they issue a library(zoo) call. The alternatives are that the user must tediously issue library(zoo) every time they issue library(xts) or else that the zoo code be copied or partially replicated into xts which would be undesirable maintenance-wise. 2. Another example is sqldf. The user wants to be able to use fn$ and other string manipulation functions in gsubfn when using sqldf in order to perform string substitution on the SQL statement. Also its desirable to be able to directly access sqlite which means the user needs access to RSQLite. 3. At one time one could just issue library(ggplot2) but now that ggplot2 does not use Depends for scales one annoyingly needs to issue library(scales) if one wants to specify a scale. I use ggplot2 enough that I can remember it despite the ongoing annoyance but I would hate to think that every package with split functionality suddenly adds such onerous requirements onto all its users. (I am not really picking on ggplot2 which is a very nice package - just this one aspect.) I am not sure but there might be additional problems if the secondary package defines an S3 generic that the primary package needs to use if one does not use Depends. On Thu, Aug 28, 2014 at 2:43 PM, Gavin Simpson wrote: > I fully agree. > > This is how I have come to understand Depends vs Imports and why I > currently will not be removing vegan from Depends for my analogue package. > This is also why I was pushing back against the notion that was voiced > early in this thread that *nothing* should be in Depends. > > Cheers > > G > > > On 28 August 2014 08:47, Bert Gunter wrote: > >> This is a nice explanation of the Imports/Depends distinction. It >> ought to go into the Extensions ref manual imho. >> >> Cheers, >> Bert >> >> Bert Gunter >> Genentech Nonclinical Biostatistics >> (650) 467-7374 >> >> "Data is not information. Information is not knowledge. And knowledge >> is certainly not wisdom." >> Clifford Stoll >> >> >> >> >> On Thu, Aug 28, 2014 at 7:39 AM, Simon Urbanek >> wrote: >> > >> > On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: >> > >> >> On 27 August 2014 15:24, Hadley Wickham wrote: >> >> >> Is that the cause of these NOTEs? Is the expectation that if I am >> using a >> function from a package, even a package that I have in Depends:, that >> I >> have to explicitly declare these imports in NAMESPACE? >> >>> >> >>> Yes. >> >>> >> >>> (Otherwise your package won't work if it's only attached and not >> >>> loaded. i.e. if someone does analogue::foo() only the imported >> >>> functions are available, not the functions in packages you depend on) >> >>> >> >> >> >> Cheers Hadley. Thanks for the confirmation, but... >> >> >> >> ...I don't get this; what is the point of Depends? I thought it was "my >> >> package needs these other packages to work, i.e. be loaded". Hence it is >> >> user error (IMHO ;-) to do `analogue::foo()` without having the >> >> dependencies loaded too. >> >> >> > >> > No. The point of Depends is that if your package is attached, it also >> attaches the other packages to make them available for the user. >> Essentially you're saying "if you want to use my package interactively, you >> will also want to use those other packages interactively". You still need >> to use import() to define what exactly is used by your package - as opposed >> to what you want to be available to the user in case it is attached. >> > >> > Cheers, >> > Simon >> > >> > >> > >> >> This check (whilst having found some things I should have imported and >> >> didn't - which is a good thing!) seems to be circumventing the >> intention of >> >> having something in Depends. Is Depends going to go away? >> >> >> >> >> >>> (And really you shouldn't have any packages in depends, they should >> >>> all be in imports) >> >> >> >> >> >> I disagree with *any*; having say vegan loaded when one is using >> analogue >> >> is a design decision as the latter borrows heavily from and builds upon >> >> vegan. In general I have moved packages that didn't need to be in >> Depends >> >> into Imports; in the version I am currently doing final tweaks on >> before it >> >> goes to CRAN I have remove all but vegan from Depends. >> >> >> >> Or am I thinking about this in the wrong way? >> >> >> >> Thanks again >> >> >> >> Gavin >> >> >> >> >> >>> >> >>> Hadley >> >>> >> >>> >> >>> -- >> >>> http://had.co.nz/ >> >>> >> >> >> >> >> >> >> >> -- >> >> Gavin Simpson, PhD >> >> >> >> [[alternative HTML version deleted]] >> >> >> >> __ >> >> R-devel@r-project.org mailing list >> >> http
Re: [Rd] Re R CMD check checking in development version of R
(Please correct me if I'm wrong. I thought I mostly understood this, finally, but I've made the mistake of thinking I understood something too many times before.) On 08/28/2014 10:39 AM, Simon Urbanek wrote: On Aug 27, 2014, at 6:01 PM, Gavin Simpson wrote: On 27 August 2014 15:24, Hadley Wickham wrote: Is that the cause of these NOTEs? Is the expectation that if I am using a function from a package, even a package that I have in Depends:, that I have to explicitly declare these imports in NAMESPACE? Yes. (Otherwise your package won't work if it's only attached and not loaded. i.e. if someone does analogue::foo() only the imported functions are available, not the functions in packages you depend on) Cheers Hadley. Thanks for the confirmation, but... ...I don't get this; what is the point of Depends? I thought it was "my package needs these other packages to work, i.e. be loaded". Hence it is user error (IMHO ;-) to do `analogue::foo()` without having the dependencies loaded too. No. The point of Depends is that if your package is attached, it also attaches the other packages to make them available for the user. Essentially you're saying "if you want to use my package interactively, you will also want to use those other packages interactively". I agree that "interactively" catches the flavour of what Depends does, but technically that is the wrong word. The important point is whether the functions in a Depended upon package should be available to the user directly without them needing to use library() or require() to make them available, in an interactive session or a batch job. You still need to use import() to define what exactly is used by your package - Amplifying a bit: By import() in the NAMESPACE, which you need whether you have Depends or Imports in the DESCRIPTION file, you ensure that the functions in your package use the ones in the package imported and do not get clobbered by anything the user might do. The user might redefine functions available to the interactive session, or require() another package with functions having the same names, and those are the ones his interactive direct calls will find, but your package functions will not use those. People are sure to have differences of opinion about the trade-off between the annoyance of having to specifically attach packages being used, and the clarity this provides. At first I was really annoyed, but have eventually decided I do like the clarity. In my experience it turns out to be surprisingly rare that you need packages in Depends, but there are legitimate cases beyond the annoyance case mentioned above. I think if you are putting packages in Depends you really do want to have a very good understanding of why you are doing that. If you use Depends then you are inviting support difficulties. Users will contact you about bugs in the package you attach, even though your package may not use the broken functions. If they attach the package themselves then they are much more likely to understand who they should contact. Core seems to have forgotten to take credit for trying to make life easier for package developers. Paul as opposed to what you want to be available to the user in case it is attached. Cheers, Simon This check (whilst having found some things I should have imported and didn't - which is a good thing!) seems to be circumventing the intention of having something in Depends. Is Depends going to go away? (And really you shouldn't have any packages in depends, they should all be in imports) I disagree with *any*; having say vegan loaded when one is using analogue is a design decision as the latter borrows heavily from and builds upon vegan. In general I have moved packages that didn't need to be in Depends into Imports; in the version I am currently doing final tweaks on before it goes to CRAN I have remove all but vegan from Depends. Or am I thinking about this in the wrong way? Thanks again Gavin Hadley -- http://had.co.nz/ -- Gavin Simpson, PhD [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
