R包开发如何抑制从依赖包生成的消息? [英] R package development how to suppress messages generated from dependency package?

查看:113
本文介绍了R包开发如何抑制从依赖包生成的消息?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个名为 VSHunter 的R包,需要 NMF 包作为依赖项,但是,每次加载时NMF会抛出很多信息,我不知道该如何压制它们。

I am developing an R package called VSHunter and need NMF package as a dependency, however, every time load NMF will throw many message, I don't know how to suppress them.

> devtools::load_all(".")
Loading VSHunter
Loading required package: NMF
Loading required package: pkgmaker
Loading required package: registry

Attaching package: ‘pkgmaker’

The following object is masked from ‘package:base’:

    isFALSE

Loading required package: rngtools
Loading required package: cluster
NMF - BioConductor layer [OK] | Shared memory capabilities [NO: 
bigmemory] | Cores 7/8
  To enable shared memory capabilities, try: install.extras('
NMF
')

我不想打扰用户并期待结果

I don't want to bother user and expect the result

> devtools::load_all(".")
Loading VSHunter

> library(VSHunter)
Loading VSHunter


推荐答案

此处在使用 devtools :: load_all

    $ b $加载软件包时,可以采取一些措施来减少噪音b
  • devtools :: load_all(...,quiet = TRUE)处理此 this 单个程序包的消息,但不一定是依赖程序包

  • 尝试在 onLoad ./ R / zzz.R 中显式加载所需的软件包。 code>函数。例如:

  • devtools::load_all(..., quiet = TRUE) handles messages for this single package, but not necessarily dependent packages
  • try explicitly loading required packages in ./R/zzz.R in the onLoad function. For example:

.onLoad <- function(libname, pkgname) {
  invisible(suppressPackageStartupMessages(
    sapply(c("tibble", "purrr", "dplyr", "tidyr", "ggplot2", "data.table"),
           requireNamespace, quietly = TRUE)
  ))
}

(顺便说一句,我使用了 sapply 这里是出于懒惰,并不是说它会增加很多东西。它很可能是 for 循环而没有任何后果。)

(BTW: I used sapply here for laziness, not that it adds much to things. It could easily have been a for loop with no consequence.)

有关使用 requireNamespace 代替的讨论,请参见库与要求 写R扩展 其中

For a discussion about the use of requireNamespace in place of library, see "library vs require", and "Writing R Extensions" where it states

包中的

R代码应调用库或仅需特殊要求。对于 Depends中列出的程序包,此类调用将不再需要,因为它们已经在搜索路径中。在使用了功能的函数中,对建议中列出的包使用require调用是一种常见的做法,但如今,最好通过::调用来访问此类功能。

R code in the package should call library or require only exceptionally. Such calls are never needed for packages listed in ‘Depends’ as they will already be on the search path. It used to be common practice to use require calls for packages listed in ‘Suggests’ in functions which used their functionality, but nowadays it is better to access such functionality via :: calls.

从技术上讲,我们不需要做什么,但是我认为通过强制这样做可以鼓励更安静的操作。 (这是

What we are doing is technically not required, but I think by forcing doing it this way, it is encouraging more-silent operation. (This rides on the coat-tails of

的小窍门。注意,我使用了 suppressPackageStartupMessages 。礼貌的包维护者使用 packageStartupMessage 而不是 message 来加载消息:后者比前者需要更多的工作并且没有太多的区别,

Notice that I used suppressPackageStartupMessages. "Courteous" package maintainers use packageStartupMessage instead of message for their loading messages: the latter takes a bit more work and is much less discriminant than the former, which is very easily suppressed without unintended consequences. There are many packages that do not do this, for which I think it's fair to submit a PR to fix.

关于此的另一条评论是,很多软件包都不这样做,我认为为此提交PR可以解决。 requireNamespace :这意味着这些软件包中的功能将不在R会话的搜索路径中。如果用户将始终使用某些软件包(例如, data.table dplyr ),那么您可能想显式地加载 library 。再次从写R扩展

Another comment about requireNamespace: this means that the functions in those packages will not be in the search path of the R sessions. If the user will always be using certain packages (e.g., data.table or dplyr), then you might want to explicitly load them with library. From "Writing R Extensions" again:


字段'Depends'如今应很少使用,仅适用于旨在o放在搜索路径上,以使最终用户可以使用它们的设施(而不是包本身):例如,有意思的是,package gridExtra的用户希望提供包晶格的功能。

Field ‘Depends’ should nowadays be used rarely, only for packages which are intended to be put on the search path to make their facilities available to the end user (and not to the package itself): for example it makes sense that a user of package latticeExtra would want the functions of package lattice made available.

但是,如果您对自己的包裹满意,那么您将使用 :: 表示法。当然,您可以使用 :: 来解决问题,但是(1)CRAN检查有时会非常激烈,(2)显式通常是一件好事(tm) ,以及(3)实际上可以使可维护性变得更加容易(例如,当依赖包更改其API / ABI并且您需要检查对其包的所有调用时,在其中搜索 pkgname :: 比分别搜索每个函数要容易得多。)

However, if you're being good about your package, then you are using :: notation for all non-base packages anyway. There are certainly ways you can get around using ::, but (1) CRAN checks are rather intense at times, (2) explicit is usually "A Good Thing (tm)", and (3) it can actually make maintainability much easier (such as when a dependent package changes their API/ABI and you need to check all calls to their package, where searching for pkgname:: is much easier than searching for each of their functions individually).

某些软件包使用 .onLoad 做得过于宽松,做并非严格必要和/或不必要的副作用的事情。为此,您始终可以编写一个函数,例如 load_deppkgs_silently(updatesearchpath = TRUE),该函数可以手动调用,也可以在有选项的情况下加载。 (我在这里考虑您的最终用户,我非常喜欢提供灵活性以及能够以自己的方式加载内容的能力。)

Some packages use .onLoad too liberally, doing things that are not strictly necessary and/or have unneeded side-effect. For this, you can always write a function such as load_deppkgs_silently(updatesearchpath=TRUE) that can be called manually or on-load with the presence of an option. (I'm thinking about your end users here, I'm a big fan of providing flexibility and the ability to not load things they way I do.)

这篇关于R包开发如何抑制从依赖包生成的消息?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆