Know which (exact) R version a package was built under? - r

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.

Related

`subgraphMining` package not available

Was unable to install the package ‘subgraphMining’. The error says "is not available (for R version 3.4.3)". What steps are needed?
There is a package named subgraphMining which you can find by searching with Google using that term. (It's not a CRAN or Github hosted package.) It's found at a book website, http://www.csc.ncsu.edu/faculty/samatova/practical-graph-mining-with-R/PracticalGraphMiningWithR.html . It does require an additional package named igraph0 and there is an answered question on SO describing that issue. The igraph0 package is likewise not "available" for the current version of R but it is in the CRAN archives. So you also need the development tools for your OS (Mac in my case, so XCode and the Command Line Tools).
siteURL <- "https://www.csc2.ncsu.edu/faculty/nfsamato/practical-graph-mining-with-R/R-code/FrequentSubgraphMining.zip"
# Since I'm not a windoze user I unzip to a local disk.
install.packages("https://cran.r-project.org/src/contrib/Archive/igraph0/igraph0_0.5.7.tar.gz",
repo=NULL, type="source")
# I downloaded the package from the chapter: Frequent Subgraph Mining
install.packages("~/Downloads/FrequentSubgraphMining/subgraphMining_1.0.tar.gz",
repo=NULL, type="source")
library(subgraphMining)
It's not written particularly well. It doesn't, for instance, list any Imports or Depends in the package DESCRIPTION file and the author of igraph thinks that the package authors should have rewritten it to use the igraph package which is currently maintained. But I think that there is quite a bit of potential value in having its installation be possible in support of what appears to be a rather interesting set of methods described in hte book.

R package listed on CRAN but not in available package

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/

Package dependency issue when testing for submissin to CRAN

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?

install other packages when creating new package in R

I created a R package called myPackage. In that package I've used other packages, such as, RJSONIO, stringr, RSQLite and Rcpp. I want to install all of those packages when I am installing myPackage, if it is not installed before.
Is this possible?
You can specify a list of packages in the DEPENDS section of your DESCRIPTION file. From the linked documentation file
The ‘Depends’ field gives a comma-separated list of package names
which this package depends on. The package name may be optionally
followed by a comment in parentheses. The comment should contain a
comparison operator, whitespace and a valid version number. You can
also use the special package name ‘R’ if your package depends on a
certain version of R — e.g., if the package works only with R version
2.11.0 or later, include ‘R (>= 2.11.0)’ in the ‘Depends’ field. You can also require a certain SVN revision for R-devel or R-patched, e.g.
‘R (>= 2.14.0), R (>= r56550)’ requires a version later than R-devel
of late July 2011 (including released versions of 2.14.0). Both
library and the R package checking facilities use this field: hence it
is an error to use improper syntax or misuse the ‘Depends’ field for
comments on other software that might be needed. Other dependencies
(external to the R system) should be listed in the
‘SystemRequirements’ field, possibly amplified in a separate README
file. The R INSTALL facilities check if the version of R used is
recent enough for the package being installed, and the list of
packages which is specified will be attached (after checking version
requirements) before the current package, both when library is called
and when preparing for lazy-loading during installation.
There are other related sections, such as IMPORTS and SUGGESTS - see the docs for details.
Have a look at some of the R-packages on r-forge to get an idea.

Possible to state explicit versions of package dependencies?

I tend to be rather explicit than implicit about the code I write. So after having managed to create my own packages, the next thing that immediately comes to my mind is how best to ensure robustness and reliability of my code. Part of that has to do with the packages my package depends on.
Actual Question
In that respect: is it possible to explicitly state which version of a package dependency is required/desired?
I'm looking for ways that don't require stating the actual path to, say, the zip file (which of course would easily be possible), but just make use of install.packages "standard behavior" of stating the package name only (possibly with some reference of the required version).
Due dilligence
I've checked Writing R Extensions to see what my options are with respect to the Depends section of the DESCRIPTION file, hoping for a similar mechanism that works for stating the required R version (e.g. R (>= 2.15.2)). But I didn't find anything similar for package dependencies:
The ‘Depends’ field gives a comma-separated list of package names which this package depends on. The package name may be optionally followed by a comment in parentheses. The comment should contain a comparison operator, whitespace and a valid version number.
You can also use the special package name ‘R’ if your package depends on a certain version of R — e.g., if the package works only with R version 2.11.0 or later, include ‘R (>= 2.11.0)’ in the ‘Depends’ field. You can also require a certain SVN revision for R-devel or R-patched, e.g. ‘R (>= 2.14.0), R (>= r56550)’ requires a version later than R-devel of late July 2011 (including released versions of 2.14.0). Both library and the R package checking facilities use this field: hence it is an error to use improper syntax or misuse the ‘Depends’ field for comments on other software that might be needed. Other dependencies (external to the R system) should be listed in the ‘SystemRequirements’ field, possibly amplified in a separate README file.
The R INSTALL facilities check if the version of R used is recent enough for the package being installed, and the list of packages which is specified will be attached (after checking version requirements) before the current package, both when library is called and when preparing for lazy-loading during installation.
Then I also had a look a install.packages and hoped for something like a version argument, but I guess there isn't.
Disclaimer
I'm perfectly aware that the goal of my questions might contrast R's philosophy of distributing and installing packages via CRAN package repositories where (at least I guess) new versions of certain packages just "overrule" previous ones and install.packages() always picks up the latest one available. It also does make a lot of sense to hide version peculiarities from the end user in order not to make things overly complex.
Yet, with respect to the goal of writing as robust code as possible, IMHO it also makes sense to state things very explicitly. Or at least to have the option to do so.
You do use Depends. For example:
Depends: R (>= 2.15.0), foo (== 1.17-12)
would place a dependency on R versions greater than or equal to 2.15.0 and on package foo being equal to 1.17-12.
(At least if I have understood you correctly, that you want to state explicitly that your package works only with version x.yy-zz of package foo.)
I'm not sure how helpful this will be for end users though; you are probably going to be forcing them to maintain separate libraries of packages in order to use your package just to maintain the exact versions you stipulate.

Resources