advise on Depends

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

advise on Depends

Kasper Daniel Hansen-2
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.

Comments?

Best,
Kasper

        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

Michael Lawrence-3
On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
[hidden email]> 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]]
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
        [[alternative HTML version deleted]]


______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

John Chambers-2
One additional point to Michael's summary:

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

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.

John

On Oct 25, 2013, at 11:26 AM, Michael Lawrence <[hidden email]> wrote:

> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
> [hidden email]> 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]]
>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

Dirk Eddelbuettel

On 25 October 2013 at 13:39, John Chambers wrote:
| One additional point to Michael's summary:
|
| The "methods" package itself should stay in Depends:, to be safe.
|
| 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.

Right.  

Our command-line / scripting frontend r from the littler package has always
defaulted to loading "methods".  And as r is a small and fully compiled
binary, it still starts up faster than Rscript by a nice margin even though
it has to load the "methods" package.  But who cares about 200 msec.  :)

Dirk

--
Dirk Eddelbuettel | [hidden email] | http://dirk.eddelbuettel.com

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

Henrik Bengtsson-3
In reply to this post by John Chambers-2
On Fri, Oct 25, 2013 at 1:39 PM, John Chambers <[hidden email]> wrote:
> One additional point to Michael's summary:
>
> The "methods" package itself should stay in Depends:, to be safe.
>
> 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 <[hidden email]> wrote:
>
>> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
>> [hidden email]> 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]]
>>>
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>       [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

Paul Gilbert-2


On 13-10-25 05:21 PM, Henrik Bengtsson wrote:
> On Fri, Oct 25, 2013 at 1:39 PM, John Chambers <[hidden email]>
> 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
>> <[hidden email]> wrote:
>>
>>> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
>>> [hidden email]> 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]]
>>>>
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________ [hidden email]
> mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

John Chambers-2
Software generated in methods for user classes calls functions in the methods package, as I said.  I don't  know the circumstances (if any) when such calls fail to find functions if  the whole package is  imported.   Perhaps someone on this list may have examples.

But for sure just importing the functions your package calls during installation (setClass(), setMethod(), etc.) won't always be enough.

When the S4 classes and methods were implemented in R in the early 2000s, it was assumed that the methods package would be considered part of the system, as the analogous code was in S.  

It would be nice to either have the package included in Rscript, CMD check, etc. or for some enterprising and very thorough person to go through and bullet-proof the generated code for the absence of the package from the search list.

Absent either of those, the defensive approach is to put methods in Depends.   Or at least, import the package rather than just the obvious functions.

John


On Oct 25, 2013, at 3:46 PM, Paul Gilbert <[hidden email]> wrote:

>
>
> On 13-10-25 05:21 PM, Henrik Bengtsson wrote:
>> On Fri, Oct 25, 2013 at 1:39 PM, John Chambers <[hidden email]>
>> 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
>>> <[hidden email]> wrote:
>>>
>>>> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
>>>> [hidden email]> 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]]
>>>>>
>>>>>
>>>>> ______________________________________________
>>>>> [hidden email] mailing list
>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>>
>>>>>
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> ______________________________________________ [hidden email]
>> mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
>>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: advise on Depends

Hervé Pagès
In reply to this post by Michael Lawrence-3
On 10/25/2013 11:26 AM, Michael Lawrence wrote:

> On Wed, Oct 23, 2013 at 8:33 PM, Kasper Daniel Hansen <
> [hidden email]> 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?

And also the user should be able to use ? to access the full
documentation of what is public. This means that if your package
defines and exports a method for a generic defined elsewhere, it should
"Depends" on the package where the generic is defined. Same thing if
your package extends a class defined elsewhere.

Cheers,
H.

>
> Michael
>
>
>> Comments?
>>
>> Best,
>> Kasper
>>
>>          [[alternative HTML version deleted]]
>>
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> [[alternative HTML version deleted]]
>
>
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: [hidden email]
Phone:  (206) 667-5791
Fax:    (206) 667-1319

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel