I am developing an R package for which I wrote some test files using R package testthatand placed the files under tests folder. I ran R CMD build on a Linux machine with R version 3.0.0. The command failed because testthat package requires R version at least 3.1.0.
Two following things I can do, but I am not sure which is better.
I can remove whole things in tests folder, so that my R package will also work for R version less than 3.1.0. As I notice, test files are not required for building an R package. Those are only useful for the developer.
I can keep all test files, but explicitly mention Depends: R (>= 3.1.0) in the DESCRIPTION file. The downside is that: (1) the package will be available to less users; and (2) more important, it depends on testthat package. Whatever updates there might affect my package potentially.
Which one do you think is better?
[update]
I followed the suggestion from # hrbrmstr, which is, I first built the package using R 3.1.0, and then check it on a Linux machine with R 3.0.0. But I still failed. The log is as follows.
* checking package namespace information ... OK
* checking package dependencies ... ERROR
Package suggested but not available: ‘testthat’
The suggested packages are required for a complete check.
Checking can be attempted without them by setting the environment
variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
Any ideas to fix this issue?Or should I take approach 1 or 2 as stated above?
Related
How can we tell precisely which R version an R package was built under?
Example
In the RSelenium package's DESCRIPTION file here, we see
Depends:
R (>= 3.0.0)
But this does not appear to be precise (due to the > symbol)
Notes
Karl Browman's site says that:
Depends is used to indicate dependency on a particular version of R, and on packages that are to be loaded (with library()) whenever your package is loaded. If you expect that users would want to load that other package whenever they loaded yours, then you should include the package name here. But this is now relatively rare. (I think the namespaces for these packages should also be imported, with #import.)
It almost never matters which version built a package. The only thing that usually matters is which version installed it. (Binary packages are images of installed packages, so it matters for them.)
The version that installed a package is stored in the Built: field in the DESCRIPTION file. (Yes, "Built", not "Installed".)
You can see it using code like
read.dcf(system.file("DESCRIPTION", package="base"), fields="Built")
#> Built
#> [1,] "R 3.6.1; ; 2019-07-06 02:01:41 UTC; unix"
Put in your own package name instead of "base".
The exception for the "almost never matters" is on those rare occasions when the package format changes.
I am asking this question because I recently solved a problem installing R Shiny (see below). However, the answers I find don't expand in detail about why this problem occurs and I really want to understand to improve my knowledge of R and why these things happen.
So my attempt to install Shiny in RStudio failed and I believe these are the important error messages:
Error in loadNamespace(i, c(lib.loc, .libPaths()), versionCheck = vI[[i]]) :
namespace 'httpuv' 1.3.3 is being loaded, but >= 1.4.3 is required
ERROR: lazy loading failed for package 'shiny'
* removing 'C:/Program Files/R/R-3.2.2/library/shiny'
* restoring previous 'C:/Program Files/R/R-3.2.2/library/shiny'
Warning in install.packages :
running command '"C:/PROGRA~1/R/R-32~1.2/bin/x64/R" CMD INSTALL -l "C:\Program Files\R\R-3.2.2\library" C:\Users\Sam\AppData\Local\Temp\RtmpuI3XHe/downloaded_packages/shiny_1.1.0.tar.gz' had status 1
Warning in install.packages :
installation of package ‘shiny’ had non-zero exit status
I went through the usual processes first to find a solution.
Checked my RStudio was up to date
Checked for and installed package updates
Among the further solutions I tried were:
Downloading the package directly from the R Studio interface
Using devtools to install Shiny from Github
Using install.packages("shiny", dependencies=TRUE).
None of these solutions worked and I believe it is to do with the dependency httpuv, but I'm not sure why.
So in the end the code I was able to use is: install.packages('shiny', type = "binary") and this allowed me to begin using Shiny.
While it wasn't too difficult for me to find a work around for this problem, I would really appreciate someone taking some time out of their day to explain why my version of RStudio in Windows (Version 1.1.456) doesn't support the source package of Shiny and why installing the binary package works. I hate fixing an issue but having zero understanding of it.
R version 3.2.2
Thank you.
Binary versus Source Code Options and Issue
You are experiencing the push-pull friction between the old and new code and R environment dependencies. The reality here is you have to choose between stability and progress. It is difficult to have both.
Consider:
You are running R version 3.2.2 in binary form, that R version was released on August 15th 2015. Yet, you are trying to install the latest source code version of Shiny.
There is a 3-year delta between the package source code version and R version you are using. The package code and R environment source code have evolved.
A lot of changes have occurred between then and now in the compile and source code environment.
Think of it this way.
The binary package image is a snapshot of the compile and source code environment assumptions at the time of compilation. If you download the current source code image you are using a snapshot of the current code environment (Now) which includes literally thousands of small incremental changes to the assumptions and dependencies in the source code files and compile environment. if you look in the shiny package description you note:
Shiny depends on httpuv which depends on Rcpp
httpuv is built on top of the libuv and http-parser C libraries.
To get httpuv to compile from source you'll need to match the R Environment, the dependent libraries and source dependencies manually. No small feat.
Case in point to compile the above packages from source code (github) you'll likely be using Devtools which if you download in binary form was compiled under R version 3.2.5.
The changes, assumptions and inter-dependencies make for a complex backport compile situation. Hence, the advantage of binary package snapshots.
Options:
In this situation, you generally have two options. You can either:
Download a source version that is old that matches your R version and environment.
The downside of this approach is you cannot access current package features.
The upside is that the package and R environment match historical context.
Upgrade to a current R environment
The downside of this approach is you have to roll with the R releases.
The upside is that you get to gain access to the latest package features made available in the current source code.
Solution Options:
How to do the above? In the first case, you might use devtools::install_git and pull the source for a particular branch or version of a package and compile it. In the second, you can upgrade your environment, and then pull and upgrade your packages.
If you want to work off a particular R environment version you have to use the binary versions. Why? These will match the R environment version coding environment assumptions.
This is a classic problem highlighting the push-pull between current code and old code. You have to choose between stability and progress. It is difficult to have both.
I hope the above helps explain the situation.
I was developing a package when I found a new error when building the package.The error makes reference to a line that previously didn't have any problem and I didn't modify. However it run smoothly in a fresh R session when I ran the code or knit the vignette alone.
Long story short: I found that this error happens when a suggested package (by my package's DESCRIPTION) is loaded before my package.
How can I control this?
The reason of the error is that my package (A) has a function is named exactly the same as the other package (B) because it does the same kind of process, but I use a different name for the same arguments (and in my version I provide other arguments as well). A solution I found is to use A::function, but that would be uglier to the reader. Is there any other solution?
This didn't happened in previous cycles of development. I have observed it on the latest R version R version 3.4.3 (2017-11-30) -- "Kite-Eating Tree" and in the devel version of R. The packages are build using both R CMD build package and devtools::check()
The conflicting package is in Suggests: part of the DESCRIPTION file of the package
This question might be related to this other one.
I want to install a package that is listed in https://cran.r-project.org/web/packages/available_packages_by_name.html as available in CRAN, but when I check in R the install packages menu or the available.packages() command, I can't see the package there.
Do I need to do something different to install those packages? Why aren't those packages available?
The packages I'm interested on are WikipediR ( https://cran.r-project.org/web/packages/WikipediR/index.html ), WikidataR and WikipediaR.
If it matters, I'm using R 2.15.0 in Windows XP.
See the documentation for ?available.packages...
By default, the return value includes only packages whose version and
OS requirements are met by the running version of R, and only gives
information on the latest versions of packages.
In other words... your R 2.15 is likely too old for the package you are looking to download.
You can try to download the package source manually add the package to the package library usually found somewhere like "win-library/2.15/" but like Cory mentioned it is likely that the older version of R does not support the package build.
The advice given so far is a bit incomplete although I do agree you need to update your R version if you want to use these packages. Looks like they don't need compilation so you might have been able to either install from a local copy or drop R code in, but critically they depend on httr which requires R 3.0.0 or above. They were released only relatively recently, so there will be no Windows binaries from back in 2012. (Your copy of R is from 30-Mar-2012.) Look in the DESCRIPTION file which is presented in a nice web format at the CRAN/package listing:
https://cran.r-project.org/web/packages/WikidataR/index.html
Imports: httr, jsonlite, WikipediR
Suggests: testthat, knitr, pageviews
# only one version of these two
https://cran.r-project.org/src/contrib/Archive/WikidataR/WikidataR_1.0.0.tar.gz
https://cran.r-project.org/src/contrib/Archive/WikipediaR/WikipediaR_1.0.tar.gz
# pick one of these
https://cran.r-project.org/src/contrib/Archive/WikipediR/
I'm building R packages in R 3.0.1 on a Windows machine, using Rtools30 and the 'Build' tools associated with RStudio, which I assume is tied in with devtools (which is up-to-date). My typical process to build a package is:
Load All
Reoxygenize
Build & Reload
Check
Build Source Package
If everything goes without errors or warnings, I then:
install.packages("foo.tar.gz", repos=NULL, type="source")
Since upgrading to R 3.0.1, I now get this warning:
Warning in install.packages :
foo.tar.gz is not available (for R version 3.0.1)
I also tried before installing, and it did not get rid of the warning:
options(install.packages.check.source = FALSE)
Also, I notice this warning when I open the devtools library:
WARNING: Rtools 3.0 found on the path at c:/Rtools is not compatible with R 3.0.1.
Which is weird, Rtools 3.0 is suppose to be good from R >2.15.1 to R 3.0.x
Any ideas what is going on?
This is RStudio specific, as they wrap and/or changed a lot of functions from the utils for better integration. The problem lies with a call to getDependencies() to check for dependencies. But that function will also check whether the original package exists on CRAN and throws the given warning when it doesn't. A package you just built on your own computer is obviously not on CRAN, hence the warning.
In the source of the native install.packages(), getDependencies() isn't called in case you build from source or install from a different repository respectively. RStudio on the other hand calls getDependencies() before it passes everything on to the native install.packages() function.
This has to my knowledge no further effects, apart from confusing people. I didn't find a way to conveniently get rid of this in RStudio, as suppressWarnings() doesn't work in this context due to the complex way RStudio deals with this.
In a basic R console, you shouldn't have any problem.
So for the time being, I'd just ignore this and hope the RStudio team finds time to take care of this minor glitch.