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.
Related
Downloaded package from below URL.
Attempted to install using below command; response shown.
library(dalton.rqi,lib.loc='/home/X/Desktop/')
Error: package ‘dalton.rqi’ was built before R 3.0.0: please re-install it
https://my.clevelandclinic.org/departments/anesthesiology/depts/outcomes-research/risk-quantification
It appears this is a compiled package that maybe I don't have the source for? Is there a way to force install of the package? I'm unable to install using Rstudio GUI in its current form as a zip. Tried repackaging to tar.gz has Rstudio was looking for and also had a non-zero exit status error.
Any ideas?
I'm afraid this can't be achieved directly. The error message says it well: to use a package in R it needs to be built on an R version matching yours.
I can suggest two ways to move forward:
Contact the authors, ask for the R sources (it is somewhat surprising they did not make them available in the first place), and build the package yourself.
Downgrade your R version as far back as needed to match the one this pre-built package used.
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 am working on a Windows 7 machine without internet access. As yet, I got around the missing internet connection by creating a local copy of the binary CRAN repository in //server/x/bin/windows/contrib/3.1, then running write_PACKAGES("//server/x/bin/windows/contrib/3.1") and finally setting r["CRAN"]="file:////server/x";r["CRANextra"]=r["CRAN"]; in C:/Program Files/R/R-3.1.2/etc/Rprofile.site.
But this does not work any longer since R 3.2.1. The path in the error message of install.packages indicates that R is looking for the source package:
Cannot open compressed file '//server/x/src/contrib/PACKAGES'
I have thought that R on Windows only looks for binary packages!
Looking at a diff between install.packages for 3.1.2 and 3.2.1, I can see quite a few changes. However, the source code for the function has 500+ lines which makes it hard for me to see where specifically the problem lies.
I have tried to set
options(install.packages.check.source="no")
and to explicitly add type="win.binary" to install.packages - both without success.
It is also interesting that
contrib.url(options("repos")$repos["CRAN"],type="win.binary")
gives the correct path file:////server/x/bin/windows/contrib/3.2 but somehow this is not used by install.packages(...,type="win.binary")...
So my question is whether you guys have experienced similar problems?
If no, I would be grateful for any pointers to mistakes I could have made.
I have found the problem.
The R 3.2.1 NEWS section (https://cran.r-project.org/src/base/NEWS) says
The default for option pkgType on platforms using binary packages is now "both", so source packages will be tried if binary versions
are not available or not up to date.
The problem is that RStudio does not directly call install.packages but via a few other functions such as .rs.callAs. In one of these functions, available.packages() gets called without any arguments. So it determines the argument type via getOption("pkgType"). But since R 3.2.1 this is now "both" and not "win.binary" as in R 3.1.2.
A quick workaround for the problem is thus to add
options(pkgType="win.binary")
to the yourRinstallpath/etc/Rprofile.site
Kind of embarrassing / a no-go, but since it hasn't been that long that I've moved from "pure user" to "beginner-developer", I've never actually read the CHANGELOG when a new R version came out - well until today (and I have the feeling I should make this a habbit) ;-)
Yet I'm not sure if the supposed change actually occurred since I couldn't find anything about it at a first glimpse at the CHANGELOG of R R 2.15.2:
Actual question
Is it possible that the (subdirectory) structure of package repositories changed from
./bin/windows/contrib/2.xx/
to
./src/contrib/2.xx/ or even ./src/contrib?
Or at least that the PACKAGES file now needs to live here: ./src/contrib/PACKAGES?
Background info
Up to version 2.15.1, the following path worked to install packages from my local package repository:
path.repos <- "L:/R/packages"
repos <- file.path("file://", path.repos)
Function contrib.url would take repos and expand it to the right subdirectory:
> contrib.url(repos)
[1] "file:///L:/R/packages/bin/windows/contrib/2.15"
But when I try to run install.packages(), I get the following error for R 2.15.2:
> install.packages("mypkg",
+ lib=file.path(R.home(), "library"),
+ repos=repos,
+ type="win.binary"
+ )
Error in read.dcf(file = tmpf) : cannot open the connection
In addition: Warning message:
In read.dcf(file = tmpf) :
cannot open compressed file 'L:/R/packages/src/contrib/PACKAGES', probable reason 'No such file or directory'
>
When I do the same with R 2.15.1, everything works smoothly.
Due dilligence
There are some references with respect to repositories in the CHANGELOG, but the only section I found that gives me some evidence that the supposed change occurred is this:
PACKAGE INSTALLATION
For a Windows or Mac OS X binary package install, install.packages() will check if a source package is available on the same repositories, and report if it is a later version or there is a source package but no binary package available.
Just had a look at the official documentation again and got the idea that maybe arg type is not passed along to contrib.url() correctly as it seems to me install.package() is looking at the place for type="source" packages?
This particular bug isn't the same as mine.
This issue relates to checks install.packages() now runs before installing. As Rappster said, it tries to find a source package to compare the binary version with:
For a Windows or Mac OS X binary package install, install.packages() will check if a source package is available on the same repositories, and report if it is a later version or there is a source package but no binary package available.
So a simple way of squashing this message is creating the R/src/contrib directory and running tools::write_PACKAGES() in that directory to create (an empty) PACKAGES file.
And of course, the reason you aren't getting this message in 2.15.1 is that it doesn't do the checking (see R NEWS quote above) that 2.15.2 performs.
I have submitted a bug report of my issues. No news yet. May post it to the R mailing list as well.