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.
Related
I'm developing a package (golem) in R, and it returns a NOTE about excess package in an Import (DESCRIPTION):
checking package dependencies … NOTE
Imports includes 34 non-default packages.
Importing from so many packages makes the package vulnerable to any of
them becoming unavailable. Move as many as possible to Suggests and
use conditionally.
I have allocated some packages in Suggests (DESCRIPTION), like this:
usethis::use_package(package = "ggplot2", type = "Suggests")
usethis::use_package(package = "MASS", type = "Suggests")
I would like to know :
What is the difference between Imports (run-time) vs Suggests (develop-time) and if the latter has anything to do with the term "compile time" of other programming languages.
How do I know a package is needed by the user at runtime? Is there any universal rule for this (like a phrase to help you know)? And for Suggests?
In R, packages listed in the Imports clause of the DESCRIPTION file must be available or your package won't load. Normally they will all be loaded when your package is loaded, though it's possible to delay that by not importing anything, just using :: notation to access them.
Packages listed in the Suggests clause don't need to be available, and won't be automatically loaded. To access their functions, you normally call requireNamespace() to find out if the package is available, and if so use :: for access. If it is not available, your package should fail gracefully in whatever the user was trying to do, letting them know that they need to install the missing package if they want the task to succeed.
These aren't really "run-time" versus "develop-time" differences. It's all run-time.
There are two things in R that might be called "compile-time" in other languages. The best match is installing your package. That configures it to the particular R version and platform it is running on. R also has a "just-in-time" compiler that optimizes functions, but other than a bit of a speed increase that is pretty much invisible to the user.
I think #r2evans answered your second question clearly in a comment: the user needs a package to use functions that use that package. If some of your functions that use it are unlikely to be used by most users, use Suggests, and add the test.
Similar Question
accessing sysdata.rda within package functions
Why This Similar Question Does Not Apply To Me
They were able to actually build it, and apparently it was a Github error for them (not related)
R VERSION
3.4.2 (I tried using 3.4.3 as well but the same problem occurred)
EDIT: I am on Windows 10
Context
I have fully read the following tutorial on R packages and how to include .Rda files in them. I have LazyData in my DESCRIPTION file set as true as well. I have tried both the data/ folder implementation and the R/sysdata.rda implementation using the function devtools::use_data() with the respective options of internal = FALSE and internal = TRUE.
However, when I try to build the package, or use devtools::install (which builds as well I assume), it fails and gives me the following error message:
Error in predict(finalModel, newInput) : object 'finalModel' not found
Where finalModel is stored within my .rda file.
Does anyone know any possible reasons why this might occur?
I also asked a coworker to install the package on his machine, but unfortunately he got the exact same error.
I made another test package as a 'sanity-check' by creating a simple linear model using the lm() function on datasets::swiss, and then made a test package with this newly created model as a .rda file. When I referenced this test model in a function within this test package, it eerily worked, despite the fact that (to the best of my knowledge) I used the exact same steps to create this new R package.
Also, I unfortunately cannot share the code for the package I am creating, but I am willing to share the code for the test package that uses the swiss dataset.
Thank you in advance.
EDIT: My .rda file I am putting in the package was created last year, if that has anything to do with it.
I just solved a similar issue of having object 'objectName' not found that arose during package management. In my case, the issue related to losing the context of variables when working with parallelization.
When using parallel::clusterExport(cl, varlist=c("function-name")), clusterExport looks at .GlobalEnv for variable definitions. This wouldn't come up during debugging, as I always the variables defined in .GlobalEnv. The solution was to state the environment explicitly: parallel::clusterExport(cl, varlist=c("function-name"), envir=environment()). This ensures that the parallel processes have context of the variables within the data/ folder and R/sysdata.rda.
Source
If you have more than one internal file, you must save them together:
usethis::use_data(file_1,
file_2,
file_3,
internal = TRUE,
overwrite = TRUE)
Title should be pretty clear I hope. I'm writing a package called forecasting, with imports for dplyr among other packages. With the imports written in to the DESCRIPTION file, I am able to force these other packages to be installed along with forecasting - is there an equivalent way to do this for the loading of the package? In other words, is there a way that when I load my package with library(forecasting), it automatically also loads dplyr and the other packages?
Thanks
Yes.
Re-read "Writing R Extensions". The Depends: forces both the initial installation as well as the loading of the depended-upon packages.
But these days you want Imports: along with importFrom() in the NAMESPACE file which is more fine-grained.
But first things first: get it working with Depends.
Edit:
Opps you're correct, the documentation I referenced is not a primary source. Perhaps this is better:
From the R documentation:
The ‘Depends’ field gives a comma-separated list of package names which this package depends on. Those packages will be attached before the current package when library or require is called.
and
The ‘Imports’ field lists packages whose namespaces are imported from (as specified in the NAMESPACE file) but which do not need to be attached. Namespaces accessed by the ‘::’ and ‘:::’ operators must be listed here, or in ‘Suggests’ or ‘Enhances’
Original:
From the R packages documentation:
Adding a package dependency here [the DESCRIPTION file] ensures that it’ll be installed. However, it does not mean that it will be attached along with your package (i.e., library(x)). The best practice is to explicitly refer to external functions using the syntax package::function(). This makes it very easy to identify which functions live outside of your package. This is especially useful when you read your code in the future.
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.
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.