advise on Depends

On 13-10-25 05:21 PM, Henrik Bengtsson wrote:

On Fri, Oct 25, 2013 at 1:39 PM, John Chambers <jmc at r-project.org>
wrote:

One additional point to Michael's summary:

The "methods" package itself should stay in Depends:, to be safe.

It would be nice to have more detail about when this is necessary, rather than suggested as a general workaround. I thought the principle of putting things in Imports was that it is safer. I have methods listed in Imports rather than Depends in 16 of my packages, doing roughly what was the basis for the original question, and I am not aware of a problem, yet.

Paul

There are a number of function calls to the methods package that
may be included in generated methods for user classes.  These have
not been revised to work when the methods package is not attached,
so importing the package only may run into problems.  This has been
an issue, for example, in using Rscript.

To clarify that last sentence for those not aware (and hopefully
spare someone having to troubleshoot this), executing R
scripts/expressions using 'Rscript' rather than 'R' differs by which
packages are attached by default.  Example:

% Rscript -e "search()" [1] ".GlobalEnv"        "package:stats"
"package:graphics" [4] "package:grDevices" "package:utils"
"package:datasets" [7] "Autoloads"         "package:base"

% R --quiet -e "search()"

search()

[1] ".GlobalEnv"        "package:stats"     "package:graphics" [4]
"package:grDevices" "package:utils"     "package:datasets" [7]
"package:methods"   "Autoloads"         "package:base"

Note how 'methods' is not attached when using Rscript.  This is
explained in help("Rscript"), help("options"), and in 'R
Installation and Administration'.

/Henrik

John

On Oct 25, 2013, at 11:26 AM, Michael Lawrence
<lawrence.michael at gene.com> wrote:

On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
kasperdanielhansen at gmail.com> wrote:

This is about the new note

Depends: includes the non-default packages: ?BiocGenerics?
?Biobase? ?lattice? ?reshape? ?GenomicRanges? ?Biostrings?
?bumphunter? Adding so many packages to the search path is
excessive and importing selectively is preferable.

Let us say my package A either uses a class B (by producing an
object that has B embedded as a slot) from another package or
provides a specific method for a generic defined in another
package (both examples using S4). In both case my impression is
that best practices is I ought to Depend on such a package, so
it is a available at run time to the user.

For classes, you just need to import the class with
importClassesFrom(). For generics, as long as your package
exports the method with exportMethods(), the generic will also be
exported from your package, regardless of whether the defining
package is attached. And the methods from the
loaded-but-not-attached packages are available for the generic.
So neither of these two is really a problem.

The rationale for Depends is that the user might always want to
use functions defined by another package with objects
consumed/produced by your package, such as generics for which
your package has not defined any methods. For example,
rtracklayer Depends on GenomicRanges, because it imports objects
from files as GenomicRanges objects.  So just consider what the
user sees when looking at your API. What's private, what's
public?

Michael

Comments?

Best, Kasper

[[alternative HTML version deleted]]

[[alternative HTML version deleted]]