[R-pkg-devel] Use of assignInNamespace in package

Martin Morgan mtmorg@n@b|oc @end|ng |rom gm@||@com
Thu Feb 7 15:44:22 CET 2019


The obvious solution is to contact the maintainer of the package generating the spurious warning and have it addressed 'at source'.

Probably it helps to be specific about the package generating the warning, the nature of the warning, and a link to your package.

I would view assignInNamespace as very poor practice -- it changes the behavior of the package conditional on whether your package is in use or not in a way that will be mysterious to most users.

Rather than using sink, one could use 'calling handlers' together with pattern matching

withCallingHandlers({
    warning("foo")
    warning("bar")
    1
}, warning = function(w) {
    if (identical(conditionMessage(w), "foo"))
        invokeRestart("muffleWarning")
})

but a significant challenge is that the text of warnings, especially from base functions, may be translated into other languages so pattern matching is not robust. In one's own code one could signal and handle specific classes of objects

withCallingHandlers({
    cond <- simpleWarning("foo")
    class(cond) <- c("my_warning", class(cond))
    warning(cond)
    warning("bar")
}, my_warning = function(...) invokeRestart("muffleWarning"))

Martin Morgan

On 2/7/19, 5:33 AM, "R-package-devel on behalf of Ege Rubak" <r-package-devel-bounces using r-project.org on behalf of rubak using math.aau.dk> wrote:

    This in not well thought through, but what about using `sink` to capture 
    any messages from the call? Then you might be able to remove the 
    expected warning and output any remaining warnings if they are there...
    
    However, note this part of `help(sink)`:
    
    Sink-ing the messages stream should be done only with great care. For 
    that stream file must be an already open connection, and there is no 
    stack of connections.
    
    Probably some of the real experts on the list can give you better advice :-)
    
    f <- tempfile(fileext = ".Rout")
    zz <- file(f, open = "wt")
    sink(zz, type = "message")
    warning("Expeced warning.")
    warning("Another warning.")
    sink(type = "message")
    mesg <- readLines(f)
    mesg
    
    /Ege
    
    On 07/02/2019 10.58, Hugh Parsonage wrote:
    > Hello,
    > 
    > I'm considering a package submission. I have used assignInNamespace,
    > which is hideous but seems better than the alternatives. I see that it
    > returns a NOTE on R CMD check, suggesting that it is not absolutely
    > prohibited, but would require justification.
    > 
    > The justification I would make is that it fixes a spurious warning
    > emitted by the namespace and that the assignInNamespace call would
    > require user intervention or the presence of an (unset) package option
    > or environment variable before being run. The alternatives would be to
    > use `suppressWarnings` (but this risks suppressing other, valid
    > warnings), to fork the package and submit the patched version as a
    > standalone package to CRAN first (which seems excessive or without
    > merit given the patch would be just one line), or to write a message
    > on package startup with the intended `assignInNamespace` call,
    > together with a recommendation to copy and run it before continuing
    > (which seems worse than assigning it within the package, considering
    > the message may be copied wrongly, and would have to be done on every
    > load).
    > 
    > I note the CRAN policy on 'malicious or anti-social' behaviour. My
    > read of 'Limited exceptions may be allowed in interactive sessions if
    > the package obtains confirmation from the user.' is that the usage
    > I've described may be allowed.  Agreement with the namespace owner
    > seems to offer another justification, though I haven't heard back from
    > the maintainer. (The patch is fairly inconsequential so the lack of
    > response is understandable.)
    > 
    > I also note the Warning in ?getFromNamespace regarding this function,
    > but as I said, it seems the least worst option.
    > 
    > 
    > Best,
    > 
    > Hugh.
    > 
    > ______________________________________________
    > R-package-devel using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-package-devel
    >
    
    ______________________________________________
    R-package-devel using r-project.org mailing list
    https://stat.ethz.ch/mailman/listinfo/r-package-devel
    


More information about the R-package-devel mailing list