[BioC] removing packages from the workspace - is this ok?
J.delasHeras at ed.ac.uk
J.delasHeras at ed.ac.uk
Thu Jun 9 14:12:36 CEST 2011
this indeed was the issue I had, which works perfectly well by
following Steve's suggestion: simply explicitly renaming objects to
ensure one deals with the correct one. The idea of explicitly
indicating the package using the double semicolon had escaped me too,
so thank you for bringing it up.
Another related matter would be: what happens when two packages use
two different functions that are however named identically? I can't
think of any right now, but I remember having come across this at some
I imagine that using the same approach (double semicolon to explicitly
indicate which package teh function is in) will work.
Is there a simple way to check a function name and return which of the
loaded packages have a function with that name? And a list of
functions included in a given package?
This seems to be somewhat basic, but I don't think I've found *one*
place to refer to all these issues. If someone can suggest a good
place to find this information and better understand all the
package/namespace/reference (double semicolon qualifier) nomenclature
& structure, I'd be very grateful.
Thank you everyone for their suggestions.
Quoting Hervé Pagès <hpages at fhcrc.org> on Wed, 08 Jun 2011 12:55:20 -0700:
> Hi Jose, Steve, Tim,
> It seems to me that the more general question Jose is asking is how
> to unambiguously refer to an object when several objects with the same
> name are defined in several packages.
> One solution is to use the "fully qualified name" of the object i.e.
> to use a <pkgname>:: prefix. For example:
> For convenience, this can be combined with Steve's suggested
> reassignment to shorter names:
> hg18 <- BSgenome.Hsapiens.UCSC.hg18::Hsapiens
> hg19 <- BSgenome.Hsapiens.UCSC.hg19::Hsapiens
> By using the "fully qualified name", the result of this reassignment
> doesn't depend on the order the packages were loaded anymore.
> On 11-06-07 02:06 PM, Tim Triche, Jr. wrote:
>> you're right, it's more of a general solution. I end up with multiple
>> versions of annotation packages, multiple namespaces' worth of S4 generics,
>> etc. floating around and it is a nice swiss army chainsaw (like many of
>> Hadley's packages) with some remaining rough edges. The ability to just
>> "find a bigger hammer" appeals to me, but a purposeful solution is probably
>> better for the problem at hand.
>> On Tue, Jun 7, 2011 at 12:53 PM, Steve Lianoglou<
>> mailinglist.honeypot at gmail.com> wrote:
>>> On Tue, Jun 7, 2011 at 2:34 PM, Tim Triche, Jr.<tim.triche at gmail.com>
>>>> One solution to the issue of managing packages in your R
>>>> namespace/environment is Hadley Wickham's devtools
>>>> I am surprised more people don't use it for this
>>> I actually tried using that a while ago in order to help make package
>>> development easier, but:
>>> (1) Isn't that more for being able to work with "source" packages w/o
>>> having to install them; and
>>> (2) as an aside, back then it had some problems with S4-isms (which
>>> may have been fixed by now)
>>> As with most all of Hadley's work -- I think devtools is (will be)
>>> great, but I don't quite see how that's the right tool for this job,
>>> though ... ?
>>> Steve Lianoglou
>>> Graduate Student: Computational Systems Biology
>>> | Memorial Sloan-Kettering Cancer Center
>>> | Weill Medical College of Cornell University
>>> Contact Info: http://cbio.mskcc.org/~lianos/contact
> 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: hpages at fhcrc.org
> Phone: (206) 667-5791
> Fax: (206) 667-1319
Dr. Jose I. de las Heras Email: J.delasHeras at ed.ac.uk
The Wellcome Trust Centre for Cell Biology Phone: +44 (0)131 6507090
Institute for Cell & Molecular Biology Fax: +44 (0)131 6507360
Swann Building, Mayfield Road
University of Edinburgh
Edinburgh EH9 3JR
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
More information about the Bioconductor