This is meant to be a FAQ question, so please be as complete as possible. The answer is a community answer, so feel free to edit if you think something is missing.
This question was discussed and approved on meta.
I am using R and tried some.function but I got following error message:
Error: could not find function "some.function"
This question comes up very regularly. When you get this type of error in R, how can you solve it?
There are a few things you should check :
Did you write the name of your function correctly? Names are case sensitive.
Did you install the package that contains the function? install.packages("thePackage") (this only needs to be done once)
Did you attach that package to the workspace ?
require(thePackage) (and check its return value) or library(thePackage) (this should be done every time you start a new R session)
Are you using an older R version where this function didn't exist yet?
Are you using a different version of the specific package? This could be in either direction: functions are added and removed over time, and it's possible the code you're referencing is expecting a newer or older version of the package than what you have installed.
If you're not sure in which package that function is situated, you can do a few things.
If you're sure you installed and attached/loaded the right package, type help.search("some.function") or ??some.function to get an information box that can tell you in which package it is contained.
find and getAnywhere can also be used to locate functions.
If you have no clue about the package, you can use findFn in the sos package as explained in this answer.
RSiteSearch("some.function") or searching with rdocumentation or rseek are alternative ways to find the function.
Sometimes you need to use an older version of R, but run code created for a newer version. Newly added functions (eg hasName in R 3.4.0) won't be found then. If you use an older R version and want to use a newer function, you can use the package backports to make such functions available. You also find a list of functions that need to be backported on the git repo of backports. Keep in mind that R versions older than R3.0.0 are incompatible with packages built for R3.0.0 and later versions.
Another problem, in the presence of a NAMESPACE, is that you are trying to run an unexported function from package foo.
For example (contrived, I know, but):
> mod <- prcomp(USArrests, scale = TRUE)
> plot.prcomp(mod)
Error: could not find function "plot.prcomp"
Firstly, you shouldn't be calling S3 methods directly, but lets assume plot.prcomp was actually some useful internal function in package foo. To call such function if you know what you are doing requires the use of :::. You also need to know the namespace in which the function is found. Using getAnywhere() we find that the function is in package stats:
> getAnywhere(plot.prcomp)
A single object matching ‘plot.prcomp’ was found
It was found in the following places
registered S3 method for plot from namespace stats
namespace:stats
with value
function (x, main = deparse(substitute(x)), ...)
screeplot.default(x, main = main, ...)
<environment: namespace:stats>
So we can now call it directly using:
> stats:::plot.prcomp(mod)
I've used plot.prcomp just as an example to illustrate the purpose. In normal use you shouldn't be calling S3 methods like this. But as I said, if the function you want to call exists (it might be a hidden utility function for example), but is in a namespace, R will report that it can't find the function unless you tell it which namespace to look in.
Compare this to the following:
stats::plot.prcomp
The above fails because while stats uses plot.prcomp, it is not exported from stats as the error rightly tells us:
Error: 'plot.prcomp' is not an exported object from 'namespace:stats'
This is documented as follows:
pkg::name returns the value of the exported variable name in namespace pkg, whereas pkg:::name returns the value of the internal variable name.
I can usually resolve this problem when a computer is under my control, but it's more of a nuisance when working with a grid. When a grid is not homogenous, not all libraries may be installed, and my experience has often been that a package wasn't installed because a dependency wasn't installed. To address this, I check the following:
Is Fortran installed? (Look for 'gfortran'.) This affects several major packages in R.
Is Java installed? Are the Java class paths correct?
Check that the package was installed by the admin and available for use by the appropriate user. Sometimes users will install packages in the wrong places or run without appropriate access to the right libraries. .libPaths() is a good check.
Check ldd results for R, to be sure about shared libraries
It's good to periodically run a script that just loads every package needed and does some little test. This catches the package issue as early as possible in the workflow. This is akin to build testing or unit testing, except it's more like a smoke test to make sure that the very basic stuff works.
If packages can be stored in a network-accessible location, are they? If they cannot, is there a way to ensure consistent versions across the machines? (This may seem OT, but correct package installation includes availability of the right version.)
Is the package available for the given OS? Unfortunately, not all packages are available across platforms. This goes back to step 5. If possible, try to find a way to handle a different OS by switching to an appropriate flavor of a package or switch off the dependency in certain cases.
Having encountered this quite a bit, some of these steps become fairly routine. Although #7 might seem like a good starting point, these are listed in approximate order of the frequency that I use them.
If this occurs while you check your package (R CMD check), take a look at your NAMESPACE.
You can solve this by adding the following statement to the NAMESPACE:
exportPattern("^[^\\\\.]")
This exports everything that doesn't start with a dot ("."). This allows you to have your hidden functions, starting with a dot:
.myHiddenFunction <- function(x) cat("my hidden function")
I had the error
Error: could not find function some.function
happen when doing R CMD check of a package I was making with RStudio. I found adding
exportPattern(".")
to the NAMESPACE file did the trick. As a sidenote, I had initially configured RStudio to use ROxygen to make the documentation -- and selected the configuration where ROxygen would write my NAMESPACE file for me, which kept erasing my edits. So, in my instance I unchecked NAMESPACE from the Roxygen configuration and added exportPattern(".") to NAMESPACE to solve this error.
This error can occur even if the name of the function is valid if some mandatory arguments are missing (i.e you did not provide enough arguments).
I got this in an Rcpp context, where I wrote a C++ function with optionnal arguments, and did not provided those arguments in R. It appeared that optionnal arguments from the C++ were seen as mandatory by R. As a result, R could not find a matching function for the correct name but an incorrect number of arguments.
Rcpp Function : SEXP RcppFunction(arg1, arg2=0) {}
R Calls :
RcppFunction(0) raises the error
RcppFunction(0, 0) does not
Rdocumentation.org has a very handy search function that - among other things - lets you find functions - from all the packages on CRAN, as well as from packages from Bioconductor and GitHub.
If you are using parallelMap you'll need to export custom functions to the slave jobs, otherwise you get an error "could not find function ".
If you set a non-missing level on parallelStart the same argument should be passed to parallelExport, else you get the same error. So this should be strictly followed:
parallelStart(mode = "<your mode here>", N, level = "<task.level>")
parallelExport("<myfun>", level = "<task.level>")
You may be able to fix this error by name spacing :: the function call
comparison.cloud(colors = c("red", "green"), max.words = 100)
to
wordcloud::comparison.cloud(colors = c("red", "green"), max.words = 100)
I got the same, error, I was running version .99xxx, I checked for updates from help menu and updated My RStudio to 1.0x, then the error did not come
So simple solution, just update your R Studio
I am creating my first package, here I am making some var estimations, the functions are running, however, I use packages that have the same function names.
Before writing the package I made an R script with the function and tests if it works, but at the top of my script I used the following code:
invisible(lapply(c("tibble","readxl","dplyr","stringr", "tidyr", "vars", "conflicted","forecast", "lubridate"), library, character.only = T))
conflict_prefer("select","dplyr")
conflict_prefer("lag", "dplyr")
conflict_prefer("filter", "dplyr")
The conflicted package chose the functions select, lag, and filter comes from the dplyr package rather from the stats package.
So I have not figured out how to use the conflict_prefer function inside the package.
Should they be the first lines of my function?
There is a roxygen way to prefer same-name functions?
I ask this because I get this warning:
> devtools::load_all()
i Loading FAVAR.MEF
Warning messages:
1: replacing previous import ‘dplyr::filter’ by ‘stats::filter’ when loading ‘FAVAR.MEF’
2: replacing previous import ‘dplyr::lag’ by ‘stats::lag’ when loading ‘FAVAR.MEF’
3: replacing previous import ‘stats::filter’ by ‘dplyr::filter’ when loading ‘FAVAR.MEF’
4: In setup_ns_exports(path, export_all, export_imports) :
Objects listed as exports, but not present in namespace: favar_est
Thanks in advance!!
If you are writing your own package and using external dependencies, you should not load them through repeated calls to library.
The proper way to do it is to state your dependencies in the DECRIPTION file of your package, which will mean that your dependencies are put on the search path in the correct order when your package is loaded. In your case, this removes the need for conflict_prefer, as dplyr will be higher up on the search path than stats. It also makes your package portable, because anyone who installs your package will have any missing dependencies installed automatically according to the packages listed in your DESCRIPTION file. Furthermore, doing it this way allows you to specify a minimum version of the dependency, so that anyone who already has an older version of the dependency installed will not come up against an obscure error when they try to use your package.
The DESCRIPTION file resides in the root directory of your package. It is a simple text file.
You need only add:
Depends:
tibble,
readxl,
dplyr,
stringr,
tidyr,
vars,
conflicted,
forecast,
lubridate
within this file, and your dependencies will be loaded with your package.
I am writing an R package that uses a variety of bioconductor annotation data packages. The specific data packages vary with the use-case. As such, I have a function which does something like this:
if (!require(biocpack_name, character.only=T)) {
source("https://bioconductor.org/biocLite.R")
BiocInstaller::biocLite(biocpack_name)
require(biocpack_name , character.only=T)
}
biocpack_name can be several of ~30+ annotation data packages that are looked up based on the particular data being analysed. As such, I don't want to have to add each to 'Suggests' (Im not even sure that would work because the error is not for a package but rather a string specifying the package). R CMD CHK gives me this error:
'library' or 'require' call not declared from: ‘biocpack_name’
'library' or 'require' call to ‘biocpack_name’ in package code.
How do I get around this?
It's not an error, but a warning. It goes away if you use character.only = TRUE rather than T (I guess because the value of TRUE is known and cannot be re-assigned, but T is unknown and can be anything, including FALSE). But in addition follow the advice in the warning to use requireNamespace() (and not pollute the user search path); maybe db = get(biocpack_name, getNamespace(biocpack_name)) will allow you to use the annotation package the way you'd like, e.g., mapIds(db, ...).
If one were pedantic, adding the packages to the Enhances: field of the DESCRIPTION file would communicate that your package somehow works with the annotation packages, but does not result in installation of the package (e.g., for building the vignette) unless explicitly requested.
Here is a snippet of R script doing beta regression on data "GasolineYield":
library("betareg")
data("GasolineYield", package = "betareg")
gy_logit <- betareg(yield ~ batch + temp, data = GasolineYield)
It works fine but if I run the code with the second line deleted, it errs with message:
Error in terms.formula(form, ...) : object 'GasolineYield' not found
But isn't the data.frame GasolineYield in the package betareg ? What's actually happening when I call library("betareg")? Aren't all the data inside the package automatically loaded into current environment? Could anybody help me understand the mechanism behind this?
For the most part, data is included in R packages for the purposes of providing examples and other stuff that is not mission critical. That is why datasets are not automatically loaded into the environment for most packages and you have to load them using the data() command. This is a good thing. It would be a waste of memory, time, and namespace for packages that primarily provide functions to load their data all the time when users don't use it very frequently.
When you load a package, only the stuff that is exported in the "NAMESPACE" file by the package designer is made available. And the "DESCRIPTION" file has a field called "LazyData" that determines the data behavior as well. By the way, packages often have functions in them that are for internal use as well and are not exported in the NAMESPACE file.
TL;DR, the package writer determines what stuff will be available when the package is loaded and they specify those items in the NAMESPACE and DESCRIPTION files.
I am maintaining an R package that recently started throwing the following warning during R CMD check packagename:
** testing if installed package can be loaded
Warning: multiple methods tables found for ‘append’
(The package is called phyloseq, and the branch that is currently causing me this problem is here)
Refined subquestions:
So the "multiple methods tables" part, this seems to imply that I have two dependent packages with a collision over dispatch for the append method. Right?
I don't have a function/method named "append" in this package, and don't import any.
I was able to reproduce the warning message in a new R session by simply loading two of the packages in R at the same time, one of which (RJSONIO) is a second-level dependency -- by which I mean one of my dependencies (biom) depends on it, but not mine:
library("RJSONIO");library("Biostrings")
Which throws the warning in the R session:
multiple methods tables found for ‘append’
And naturally, append is exported in the NAMESPACE file of both RJSONIO and Biostrings. What I don't understand is why this should cause a problem when loading my package. The packages I directly depend on (Biostrings-2.28.0, biom-0.3.8) are not fully imported -- certainly not importing any append methods. How else could this conflict arise?
Workaround:
If I update Biostrings to the "devel" version, 2.29.2, then the warning appears to go away. Most users will not do this, however, and I'd still like to understand how this collision is even possible, given the way I specifically imported functions and classes from these packages rather than full Import or Depends.