[Bioc-devel] depends on packages providing classes

[Vincent Carey]

On Tue, Oct 28, 2014 at 11:23 AM, Kasper Daniel Hansen <
kasperdanielhansen at gmail.com> wrote:

> Well, first I want to make sure that there is not something special
> regarding S4 methods and classes. I have a feeling that they are a special
> case.
>
> Second, while I agree with Jim's general opinion, it is a little bit
> different when I have return objects which are defined in other packages.
> If I don't depend on this other package, the user is hosed wrt. the return
> object, unless I manually export all classes from this other
>

In what sense?  If you return an instance of GRanges, certain things can be
done
even if GenomicRanges is not attached.  You can get values of slots, for
example.

With the following little package

%vjcair> cat foo/NAMESPACE

importFrom(IRanges, IRanges)

importClassesFrom(GenomicRanges, GRanges)

importFrom(GenomicRanges, GRanges)

export(myfun)



%vjcair> cat foo/DESCRIPTION

Package: foo

Title: foo

Version: 0.0.0

Author: VJ Carey <stvjc at channing.harvard.edu>

Description:

Suggests:

Depends:

Imports: GenomicRanges

Maintainer: VJ Carey <stvjc at channing.harvard.edu>

License: Private

LazyLoad: yes



%vjcair> cat foo/R/*

myfun = function(seqnames="1", ranges=IRanges(1,2), ...)

   GRanges(seqnames=seqnames, ranges=ranges, ...)


The following works:


> library(foo)

> x = myfun()

> x

GRanges object with 1 range and 0 metadata columns:

      seqnames    ranges strand

         <Rle> <IRanges>  <Rle>

  [1]        1    [1, 2]      *

  -------

  seqinfo: 1 sequence from an unspecified genome; no seqlengths


So the show method works, even though I have not touched it.  (I did not

expect it to work, in fact.)  Additionally, I can get access to slots.  But
ranges()

fails.  If I, the user, want to use it, I need to arrange for that.


In some cases you'll decide you want the user to have a full complement of

methods for your package to function meaningfully.  For example, I am
considering

using dplyr idioms to work with data structures in a package, and it seems
I should

just depend on dplyr rather than pick out and document which things I want
to expose.  But that

may still be an undesirable design.


> package, like
>   importClassesFrom("GenomicRanges", "GRanges")
>   exportClasses("GRanges")
> Surely that is not intended.
>
> It is important that my package works without being attached to the search
> path and I do this by carefully importing what I need, ie. my code does not
> require that my dependencies are attached to the search path.  But the end
> user will be hosed without it.
>
> My impression is that the NOTE in R CMD check was written by someone who
> did not anticipate large-scale use and re-use of classes and methods across
> many packages.
>
> Best,
> Kasper
>
>
> On Tue, Oct 28, 2014 at 11:14 AM, James W. MacDonald <jmacdon at uw.edu>
> wrote:
>
>> I agree with Vince. It's your job as a package developer to make
>> available to your package all the functions necessary for the package to
>> work. But I am not sure it is your job to load all the packages that your
>> end user might need.
>>
>> Best,
>>
>> Jim
>>
>>
>>
>> On Tue, Oct 28, 2014 at 11:04 AM, Vincent Carey <
>> stvjc at channing.harvard.edu> wrote:
>>
>>> On Tue, Oct 28, 2014 at 10:19 AM, Kasper Daniel Hansen <
>>> kasperdanielhansen at gmail.com> wrote:
>>>
>>> > What is the current best paradigm for using all the classes in
>>> > S4Vectors/GenomeInfoDb/GenomicRanges/IRanges
>>> >
>>> > I obviously import methods and classes from the relevant packages.
>>> >
>>> > But shouldn't I depend on these packages as well?  Since I basically
>>> want
>>> > the user to have this functionality at the command line? That is what
>>> I do
>>> > now.
>>> >
>>> >
>>> I've wondered about this as well.  It seems the principle is that the
>>> user
>>> should
>>> take care of attaching additional packages when needed.  It might be
>>> appropriate
>>> to give a hint in the package startup message, if having some other
>>> package
>>> attached
>>> would typically be of great utility.
>>>
>>> Given your list above, I would think that depending on GenomicRanges
>>> would
>>> often
>>> be sufficient, and IRanges/S4Vectors would not require dependency
>>> assertion.  I would
>>> think that GenomeInfoDb should be a voluntary attachment for a specific
>>> session.
>>>
>>> These are just my guesses -- I doubt there will be complete consensus,
>>> but
>>> I have
>>> started to think very critically about using Depends, and I think it is
>>> better when its
>>> use is minimized.
>>>
>>>
>>> > That of course leads to the R CMD check NOTE on depending on too many
>>> > packages.... I guess I should ignore that one.
>>> >
>>> > Best,
>>> > Kasper
>>> >
>>> >         [[alternative HTML version deleted]]
>>> >
>>> > _______________________________________________
>>> > Bioc-devel at r-project.org mailing list
>>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>> >
>>>
>>>         [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>>
>> --
>> James W. MacDonald, M.S.
>> Biostatistician
>> University of Washington
>> Environmental and Occupational Health Sciences
>> 4225 Roosevelt Way NE, # 100
>> Seattle WA 98105-6099
>>
>
>

	[[alternative HTML version deleted]]