Prev 9009 / 21312 Next

[Bioc-devel] namespace question

Michael Lawrence

Tue, Apr 5, 2016 11:28 AM

Roxygen does not yet support the feature. For now you'll have to live
with the warning or just importFrom(shiny, ...). Maybe there is some
way to manually patch the NAMESPACE with Roxygen?

Honestly, I would recommend against using Roxygen to manage your
NAMESPACE. Just write the thing...

On Tue, Apr 5, 2016 at 11:07 AM, Karim Mezhoud <kmezhoud at gmail.com> wrote:

Hi,
Actually I have conflict between DT and shiny
 Warning: replacing previous import ?shiny::dataTableOutput? by
?DT::dataTableOutput? when loading ?bioCancer?
  Warning: replacing previous import ?shiny::renderDataTable? by
?DT::renderDataTable? when loading ?bioCancer?

I would like to import shiny except dataTableOutput and renderDataTable.

#'@import shiny except dataTableOutput renderDataTable
I am using roxygen2
R Under development (unstable) (2016-03-11 r70310)
Which package Can I update to get the new import argument.
Thanks
Karim


On Tue, Apr 5, 2016 at 6:50 PM, Michael Lawrence <lawrence.michael at gene.com>
wrote:

I will try to sneak that in since it seems to work and it would be
nice to use it before this Fall.

On Tue, Apr 5, 2016 at 10:32 AM, Dan Tenenbaum <dtenenba at fredhutch.org>
wrote:

Michael, do you know if this change will be (or has already been)
backported into R-3.3.0?

Thanks.
Dan


----- Original Message -----

From: "Lihua Zhu" <Julie.Zhu at umassmed.edu>
To: "Dan Tenenbaum" <dtenenba at fredhutch.org>, "Michael Lawrence"
<lawrence.michael at gene.com>
Cc: "bioc-devel" <bioc-devel at r-project.org>
Sent: Tuesday, April 5, 2016 9:49:26 AM
Subject: Re: [Bioc-devel] namespace question

Dan,

That is great! Thanks for letting us know!

Michael, thank for making it happen so quickly! It works like a charm!

Best,

Julie

On 4/2/16 1:58 PM, "Bioc-devel on behalf of Dan Tenenbaum"
<bioc-devel-bounces at r-project.org on behalf of dtenenba at fredhutch.org>
wrote:

BTW, looks like the change has been made to R-devel:

#### CHANGES IN R-devel NEW FEATURES

 * The ?import()? namespace directive now accepts an argument ?except?
which names symbols to exclude from the imports. The ?except?
expression
should evaluate to a character vector (after substituting symbols for
strings). See Writing R Extensions.

URL:

https://urldefense.proofpoint.com/v2/url?u=http-3A__developer.r-2Dproject.

org_blosxom.cgi_R-2Ddevel_NEWS_2016_04_02-23n2016-2D04-2D02&d=BQIGaQ&c=WJB

j9sUF1mbpVIAf3biu3CPHX4MeRjY_w4DerPlOmhQ&r=3IbW-yoIQpGZOKgd4i2bgmPHhwHHF5g

JMlij5cC5bLU&m=HCJuUKMo50mOyjfD0AtQzV69c0SnACXTGdX_iHcWRfo&s=MbBj5lNGwkIfP

hrHI2clfQd1aq1yPyROa3utKrCP4ug&e=



----- Original Message -----

From: "Michael Lawrence" <lawrence.michael at gene.com>
To: "Herv? Pag?s" <hpages at fredhutch.org>
Cc: "Michael Lawrence" <lawrence.michael at gene.com>, "bioc-devel"
<bioc-devel at r-project.org>
Sent: Saturday, April 2, 2016 4:10:10 AM
Subject: Re: [Bioc-devel] namespace question

Also, just btw, there are two other places where arbitrary R code can
be evaluated in the NAMESPACE, but no one has abused them yet. as far
as I know. The first argument to if() and the .fixes argument to
useDynLib(). The latter sets the precedent for the except= behavior.
Although someone forgot to document it, you can do .fixes=c("prefix",
"suffix") to both prefix and suffix incoming native symbols.
Currently, the documentation only mentions prefixing. Not sure when
suffixing would be desirable.


On Fri, Apr 1, 2016 at 4:14 PM, Herv? Pag?s <hpages at fredhutch.org>
wrote:

On 04/01/2016 01:39 PM, Michael Lawrence wrote:

Yes, it's arbitrary R code that is evaluated, so paste0() would
work.
You're right that it's a big door and could let people do weird
things. Do you foresee a problem with that?


Opening such a big door raises many questions. In addition to
allowing
people do weird/crazy things (like putting calls to library()
or requireNamespace() etc... in them), NAMESPACE files with
arbitrary
R code in them become more complicated to maintain and the tools for
parsing/processing them also become more complicated to write and
maintain.

Now we have a new category of errors that can happen at package
installation time: errors triggered by the evaluation of the R
expressions embedded in the NAMESPACE file. Hopefully 'R CMD
INSTALL'
will report something that can be understood by mere mortals when
this
happens.

Once you create the feeling that a NAMESPACE file is just a file
that contains arbitrary R code then people expect import(), export()
etc.. to be ordinary R functions with a man page (being able to do
?import would not hurt actually) and they'll naturally try to do
things like

  unwanted_foo_symbols <- ... long and complicated expression
                              eventually calling user-defined helper
                              functions located in the NAMESPACE
file
...
  import(foo, except=unwanted_foo_symbols)

Can't blame them for that. But is this the kind of things that we're
ready to see in NAMESPACE files?

Also once you've open that door, people will naturally wonder why
they
can use an R expression in the 'except' part of import( , except=)
but
not elsewhere e.g. in

  import(foo, only=paste0("bar", 1:10))

as a more elegant way of doing importFrom(foo, bar1, bar2, ...,
bar10).
This dissymmetry between the syntax of "import only this" and
"import
all except this" feels very arbitrary. If you don't support the
import( , only=) syntax, people might legitimately ask things like

  do.call(importFrom, c(list("foo"), as.list(paste0("bar", 1:10))))

to work. Again, can't blame them for that. But do we want this kind
of
things to work? I'm worried debugging NAMESPACE files would become a
full-time job...

I guess one could have implemented NAMESPACE parsing by evaluating
the
code in an environment (inheriting from the base namespace) where
import(), export(), etc, were defined. Maybe there's a good reason
why
it was not implemented that way.


I'm sure there is ;-)

H.

On Fri, Apr 1, 2016 at 12:55 PM, Herv? Pag?s <hpages at fredhutch.org>
wrote:

On 03/31/2016 04:07 PM, Michael Lawrence wrote:


I agree. The importExcept idea also works that way:
importExcept(foo,
bar,
baz)

But import(foo, except=c(bar, baz)) reads better.



mmh... so R expressions with calls to base functions like
base::c()
are
making their way in the NAMESPACE file. That's opening a big door.
Does
that mean that we'll be able to do things like:

import(foo, except=paste0("bar", 1:10))

Or maybe c(bar, baz) in your above example is just an arbitrary
syntax
that just happens to look like an R expression but won't be
evaluated
as such?


H.


On Thu, Mar 31, 2016 at 4:00 PM,  <luke-tierney at uiowa.edu> wrote:


I don't think you want to separate it from the import. Better to
allow
something like

import(foo, exclude=bar)

or

import(foo, exclude=c("bar", "baz"))

This seems reasonably natural and shouldn't be too hard to
implement. (But is has been a while since I've worked on this
code).

Best,

luke


On Thu, 31 Mar 2016, Karim Mezhoud wrote:

I think "From" is needed to specify which package we want to
exlude
functions.

I think  excludeFrom (package, function)  seems to be
intuitive.

thanks,
Karim



On Thu, Mar 31, 2016 at 9:54 PM, Herv? Pag?s
<hpages at fredhutch.org>
wrote:

On 03/31/2016 12:55 PM, Michael Lawrence wrote:

Probably should just stick to exact symbols for now. If there
is a
case where a pattern is actually useful, rather than just an
obfuscation, we can extend the feature set.

Fair enough. Not really intuitive that excludeImport uses the
same
syntax as (but does the opposite of) importFrom though. Maybe
having
the name of the directive start with "import" would help e.g.

importExcept(hash, values)  # opposite of importFrom(hash,
values)

Thanks,
H.

On Thu, Mar 31, 2016 at 12:11 PM, Zhu, Lihua (Julie)
<Julie.Zhu at umassmed.edu> wrote:

Herve,

That is a very interesting idea and works for me! Thanks!

importPatternFrom(IRanges, "^values$")


Best,

Julie

On 3/31/16 2:51 PM, "Bioc-devel on behalf of Herv? Pag?s"
<bioc-devel-bounces at r-project.org on behalf of
hpages at fredhutch.org>
wrote:

On 03/30/2016 08:35 PM, Michael Lawrence wrote:

That would work, but R is not going to be happy about
redundant
imports. Interactively, users would balk at symbol
qualification.

There are two classes of conflict:
1) Same semantics, where a common generic would arbitrate,
or one
package could depend on the other, and
2) Different semantics, in which case one of the functions
should
probably be renamed, although that might not be practical
or
easy
to
agree upon.

When those approaches fail, qualification is the only
recourse.

I will think about adding an excludeImport() or
importAs().

What about having something like an importPatternFrom()
directive
similar to the exportPattern() directive and have these
directives
support some of the grep() toggles like 'ignore.case',
'fixed',
'invert' etc... ?

Then Julie could just do:

importPatternFrom(hash, "^values$", invert=TRUE)

H.

On Wed, Mar 30, 2016 at 8:20 PM, Robert M. Flight
<rflight79 at gmail.com

wrote:

In the cases of having conflicting names, is it not
appropriate
then
to use
the "package::function" form for calling a particular
function?

On Wed, Mar 30, 2016 at 11:14 PM Michael Lawrence
<lawrence.michael at gene.com>
wrote:

I can't find the hash function in IRanges. Are you sure
it
has
one?




On Wed, Mar 30, 2016 at 8:07 PM, Zhu, Lihua (Julie)
<Julie.Zhu at umassmed.edu> wrote:

Michael,

I have the same user case as Kasper. Another example is
that
both
IRanges
and hash packages have hash. I need to use the hash
from
the
hash
package
instead of the one from IRanges.

Best,

Julie

On Mar 30, 2016, at 7:57 PM, Kasper Daniel Hansen
<kasperdanielhansen at gmail.com> wrote:

My usecase is when I import() two packages who has a
conflict
in
a
name.
For example, both Biobase and matrixStats has both
anyMissing
and
rowMedians. I am happy to get all of these two
packages,
but I
need
to
resolve the conflict.  Since I want to keep the ones
from
matrixStats I

know

need to figure out how to import Biobase selectively.
Which I
can,
using
the tools from codetoolsBioC, but I would also be happy
with
an
importFromExcept(), which would make my life much
easier.

Best,
Kasper

On Wed, Mar 30, 2016 at 4:47 PM, Michael Lawrence
<lawrence.michael at gene.com> wrote:

I'm curious about which symbols you wouldn't want to
import,
and
why.

On Wed, Mar 30, 2016 at 12:19 PM, Zhu, Lihua (Julie)
<Julie.Zhu at umassmed.edu> wrote:

Hi,

Is there a function to import all the exported
objects
from
a
package
except a few named ones in NAMESPACE file?

For example, I would like to import all the functions
in
S4Vectors
except fold. Is there a way to  specify this without
listing
all
other
functions using importFrom?

Many thanks for your help!

Best regards,

Julie

********************************************
Lihua Julie Zhu, Ph.D
Research Professor
Department of Molecular, Cell and Cancer Biology
(MCCB)
Head of MCCB Bioinformatics Core
Program in Molecular Medicine
Program in Bioinformatics and Integrative Biology
University of Massachusetts Medical School
364 Plantation Street, Room 613
Worcester, MA 01605
508-856-5256 phone
(508) 856 5460 fax

http://profiles.umassmed.edu/profiles/ProfileDetails.aspx?Fr

om=SE&Perso
n=1134

            [[alternative HTML version deleted]]

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list

_______________________________________________
Bioc-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Thread (11 messages)

Zhu, Lihua (Julie) namespace question Apr 5 Dan Tenenbaum namespace question Apr 5 Michael Lawrence namespace question Apr 5 Karim Mezhoud namespace question Apr 5 Michael Lawrence namespace question Apr 5 Karim Mezhoud namespace question Apr 5 Michael Lawrence namespace question Apr 5 Karim Mezhoud namespace question Apr 5 Michael Lawrence namespace question Apr 5 Karim Mezhoud namespace question Apr 7 Martin Morgan namespace question Apr 7