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-boun...@r-project.org on behalf of ru...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
