This question already has answers here:
Elegant way to check for missing packages and install them?
(33 answers)
Closed 4 years ago.
The typical way a package developer is advised to check whether a user has installed a package is like this:
if (!requireNamespace("package")) {
stop("Please install package.")
}
requireNamespace loads the package (in the current scope?) and returns a TRUE/FALSE value. I need to check the install state of a package without loading the namespace.
The reason for this is because I am writing a knit_print S3 method (extending the knitr package) and the namespace I am checking for kableExtra has side effects outside of the context of my knit_print method that I want to avoid.
When loaded, kableExtra changes how subsequent calls to knitr::kable are formatted at the global level. It has good reasons for doing so, but I want to use kableExtra inside my S3 method and not have end users confused about why kable behaves differently after my knit_print method is called.
That's why I want to do the check for the namespace (and if kableExtra is not installed, just call knitr::normal_print) without loading the namespace.
Edit: To clarify why I don't think this is a duplicate of this question, those answers do not pay any special attention to whether the solution loads the package when it is installed. It turns out that some of the solutions do not load the package in question, but they are not clearly differentiated.
Use installed.packages.
if ("kableExtra" %in% rownames(installed.packages()) {
# do something
}
Related
Currently I have in my package DESCRIPTION, a dependency on dbplyr:
Imports:
dbplyr,
dplyr
dbplyr is useful almost solely because of the S3 methods it defines: https://github.com/tidyverse/dbplyr/blob/main/NAMESPACE. The actual functions you call to use dbplyr are almost entirely from dplyr.
By putting dbplyr in my Imports, it should automatically get loaded, but not attached, which should be enough to register its S3 methods: https://r-pkgs.org/dependencies-mindset-background.html#sec-dependencies-attach-vs-load.
This seems to work fine, but whenever I R CMD check, it tells me:
N checking dependencies in R code (10.8s)
Namespace in Imports field not imported from: ‘dbplyr’
All declared Imports should be used.
Firstly, why does R CMD check even check this, considering that it often makes sense to load packages without importing them. Secondly, how am I supposed to satisfy R CMD check without loading things into my namespace that I don't want or need?
I am pretty sure two of your assumptions are false.
First, putting Imports: dbplyr into your DESCRIPTION file won't load it, so its methods won't be loaded from that alone. Basically the Imports field in the DESCRIPTION file just guarantees that dbplyr is available to be loaded when requested. If you import something via the NAMESPACE file, that will cause it to be loaded. If you evaluate dbplyr::something that will cause it to be loaded. Executing loadNamespace("dbplyr") is another way, and there are a few others. You may also load some other package that loads it.
Second, I think you have misinterpreted the error message. It isn't saying that you loaded it without importing it (though it would complain about that too), it is saying that it can't detect any use of it in your package, so maybe it shouldn't be a requirement for installing your package.
Unfortunately, the code to detect uses is fallible, so it sometimes misses uses. Examples I've heard about are:
if the package is only used in the default value for a function argument. This has been fixed in R-devel.
if the package is only used during the build to construct some object, e.g. code like someclass <- R6::R6Class( ... ) needs R6, but the check code won't see it because it looks at someclass, not at the source code that created it.
if the use of the package is hidden by specifying the name of the package in a character variable.
if the need for the package is indirect, e.g. you need to use ggplot2::geom_hex. That needs the hexbin package, but ggplot2 only declares it as "Suggested".
These examples come from this discussion: https://github.com/hadley/r-pkgs/issues/828#issuecomment-1421353457 .
The recommended workaround there is to create an object that refers to the imported package explicitly, e.g. putting the line
dummy_r6 <- function() R6::R6Class
into your package is enough to suppress the note without actually loading R6. (It will be loaded if you ever call this function.)
However, your requirement is stronger: you do need to make sure dbplyr is loaded if you want its methods to be used. I'd put something in your .onLoad() function that triggers the load. For example,
.onLoad <- function(lib, pkg) {
# Make sure the dbplyr methods are loaded
loadNamespace("dbplyr")
}
EDITED TO ADD: As pointed out in the comments, there's a bug in the check code that means it won't detect this as being a use of dbplyr. You really need to do both things, e.g.
.onLoad <- function(lib, pkg) {
# Make sure the dbplyr methods are loaded
loadNamespace("dbplyr")
# Work around bug in code checking in R 4.2.2 for use of packages
dummy <- function() dbplyr::across_apply_fns
}
The function used in the dummy construction is arbitrary; it probably doesn't even need to exist, but I chose one that does.
I am using the devtools package to check if a package I am developing is ready for submission to CRAN.
Using Roxygen2 through devtools, I documented a small number of functions with #'#export, in order for them to be available when the package I am developing is loaded.
However, when I run devtools::check(), it seems I need to document the functions that are NOT exported, i.e. those that may be called by a function which is exported, but which are not available nor needed by whoever uses the package. Here is an example from the output of devtools::check():
checking Rd \usage sections ... WARNING
Undocumented arguments in documentation object 'calculate_agreement'
‘a_assign_star’ ‘a_assign’
Do I need to document those arguments although the function is not exported?
I believe the problem here (based on past experience) is that you are probably using Roxygen comment delimiters #' in the preamble to the function. This (I'm pretty sure) triggers the creation of a .Rd file (and the need to document parameters), whether or not you have an #export directive or not. My solution in this case was to use regular # commenting rather than #'.
Based on this answer it's possible that an explicit #keywords internal directive would also work (but I haven't tried it).
I've hit an issue trying to import a package (namely, 'robfilter') inside one of my own packages. One of its methods that I am trying to use, adore.filter, is failing at this line:
data(critvals)
With error 'data set 'critvals' not found'.
The function works fine if I load the library via require(robfilter). However, this means that in order to use my custom package which calls adore.filter, I will have to load my own package, and then load robfilter. Not a huge problem but slightly annoying.
I'm not sure if the problem is that there is an extra step I need to do in order to make critvals visible within my package, or if perhaps there is something the package author needed to do (and hasn't done) to add critvals to its package namespace; there is no sign of 'critvals' in the robfilter NAMESPACE file. I haven't encountered this issue before and don't really understand how the use of data() inside a package is supposed to work.
There are two solutions as far as I know:
Either ask the robfilter Maintainer to put the data needed by robfiler in the internal data file of robfilter. (R/sysdata.rda)
Or make your package Depends on robfilter
So it works if you put robfilter in the depends section of your description file. But in my case (both are my packages), I was trying to avoid the Depends solution as it loads the imported package and also any other package will need to depend ont its imported package... See my question is quite a duplicate of yours but not in the same context.
This question already has answers here:
Elegant way to check for missing packages and install them?
(33 answers)
Closed 9 years ago.
Is there a "standard" way to load a package, and install it if it isn't installed yet? Something like
if (!is.installed(package))
install(package)
library(package)
(pseudocode!), encapsulated in a neat function?
I'm usually having a hard time after wiping my private site library, which I do every now and then. If my scripts all used this "install-on-demand" facility, this would just happen automatically.
Dason K. and I have a package in the works on GitHub that needs some testing and a bit of cleaning and eventually will be pushed to CRAN. The function p_load in the package does this.
library(devtools)
install_github("trinker/pacman")
I see that other answers have been given but my preference would be:
if ( !require('pkg') ) { install.packages('pkg', dependencies=TRUE);
require('pkg') }
If you want to suppress the warning, then add quietly=TRUE to the first require call. I suppose you could bundle this into a function, called, what? insist?
insist <- function(pkg){
if ( !require(pkg, character.only=TRUE) ) {
install.packages(as.character(pkg), dependencies=TRUE)
require(pkg, character.only=TRUE) }
}
(My major stumbling block: The first argument to require didn't seem to get evaluated unless character.only=TRUE. Took me several reads of the ?require page to get this idea. Just slow, I guess.)
Suppose I'm currently developing a package called mypackage. As time goes by, many different functions have landed in there, and I want to reorganize it. So I'd like to create a new package called newpackage in which I would move some of the functions of mypackage (and include new ones later).
The problem is that I don't want original users of mypackage to get object not found errors when they want to use one of the moved functions.
So, I thought about doing the following :
create newpackage and move the functions
add into mypackage DESCRIPTION file : Depends: newpackage
As such, when people would install, upgrade or load mypackage, newpackage would be installed or loaded too, and all the functions would be available.
Do you think it would work, or would there be some problems I don't think about ?
Thanks !
Isn't it so that it is not recommended to remove functions from a package without labeling them first to be depreciated?! So, maybe you proceed as you planned but before removing them from the mypackage, you could first mark them there as depreciated and then remove them from it finally in the next version of the package. And during the migrating phase you could use the namespace of the packages to refer already to the function in newpackage as you planned.