Open weshinsley opened 5 months ago
The build process for the INLA R package requires a manual step of first building the standalone inla binary executable, so no INLA package version can be built purely using the normal R build process. When installing from the repositories, one cannot "build" the package in a working format, as that will not include the executable, so "building from source" will not work on any R version, or any existing INLA source code version, without manual intervention. This may be improved in the future, but the build process is difficult to fully automate.
The "stable" repository cannot yet be used with R 4.4, as only the testing version has been built for R 4.4, currently one must use testing with 4.4, and stable with 4.3. But yes, the missing binary for 24.05.10 will cause an issue. R should let you specify that you only want "binary" installation, which should work around the issue without needing to specify the version (as that's not supported by install.packages()
):
install.packages("INLA", repos = ..., type = "binary")
The documentation for install.packages
contains a further option:
For a binary install from a repository, the function checks for the availability of a source package on the same repository, and reports if the source package has a later version, or is available but no binary version is. This check can be suppressed by using
options(install.packages.check.source = "no")
and should be if there is a partial repository containing only binary files.
OK - thanks for these workarounds - but just to highlight the immediate problem - So if we want to use the stable version, we should use R 4.3 for now - fine - but if an R 4.3 user follows the installation instructions from here (https://www.r-inla.org/download-install) - which say:
install.packages("INLA",repos=c(getOption("repos"),INLA="https://inla.r-inla-download.org/R/stable"), dep=TRUE)
that will fail with the error message I got above because it will try to install 24.05.10 from source. So I think for now, either updating the installation instructions with the workaround to make install.packages not do that, or filling in the missing binary in the 4.3 folder might be helpful to do.
Further - I tested on R 4.3 with options(install.packages.check.source = "no")
- but it made no difference:-
> options(install.packages.check.source = "no")
> install.packages("INLA",repos=c(getOption("repos"),INLA="https://inla.r-inla-download.org/R/stable"), dep=TRUE)
Warning in install.packages :
partial argument match of 'dep' to 'dependencies'
Installing package into ‘E:/Rlib’
(as ‘lib’ is unspecified)
Warning in install.packages :
dependencies ‘Rgraphviz’, ‘graph’ are not available
There is a binary version available but the source version is later:
binary source needs_compilation
INLA 24.05.01-1 24.05.10 FALSE
installing the source package ‘INLA’
trying URL 'https://inla.r-inla-download.org/R/stable/src/contrib/INLA_24.05.10.tar.gz'
Content type 'application/x-gzip' length 61448956 bytes (58.6 MB)
downloaded 58.6 MB
* installing *binary* package 'INLA' ...
C:\WINDOWS\cp.exe: invalid option -- )
Try `C:\WINDOWS\cp.exe --help' for more information.
ERROR: installing binary package failed
* removing 'E:/Rlib/INLA'
Warning in install.packages :
installation of package ‘INLA’ had non-zero exit status
The downloaded source packages are in
‘E:\Rtmp\Rtmp4ows8C\downloaded_packages’
For now, an explicit INLA version, for which a binary exists for that R-version seems to be the only workaround - or pressing ahead with R 4.4 regardless, where the binary does seem to exist.
Did the type = "binary"
method work?
I see in the NEWS.md file that 24.05.10 was the first R 4.4 build, so the error with that one is that it shouldn't be present in any form in the 4.3 folder.
Have you found a method for specifying a specific INLA version that actually works? I don't see an option for that in install.packages
, and I don't have access to try remotes::install_version()
on Windows.
type = "binary"
on the install.packages did work - it picked the most recent binary correctly.
trying URL 'https://inla.r-inla-download.org/R/stable/bin/windows/contrib/4.3/INLA_24.05.01-1.zip'
Yes, so the issue then is why does it still try to build 24.05.10 from source in R 4.3
It tries to build it because it finds a newer source package. I would have expected turning off that check to have fixed it; that may be an error in the install.packages
documentation for that feature.
The most generally useful approach on windows and macos seems to be for such users to always specify type = "binary"
when installing INLA, so that seems to be the hint that needs to be added to the webpage. That way, the instruction will work also in future cases, and not having to rely on specific version instructions.
Have you found a method for specifying a specific INLA version that actually works? I don't see an option for that in
install.packages
, and I don't have access to tryremotes::install_version()
on Windows.
Yes, you're right - and further remotes::install_version requires type="source". So type="binary" on install.packages indeed seems the best option, since building from source on Windows does not seem likely to be possible.
(On our cluster, we use pkgdepends, which can let us specify both the repo and version)
I see that https://www.r-inla.org/download-install already does mention the remotes::install_version()
option, specifically in the context of the transition period when INLA gets built for new R versions. But I think as long as the available packages in the repository section for each version are correct, then the install.packages(..., type = "binary")
option would be sufficient. So removing the 24.05.10 source package from the 4.3 section might make the type
argument the only thing needed to handle the issue for all R versions.
I think all the instructions for remotes::install_version probably need reviewing.
From R 4.3, the instructions there do the following:-
> remotes::install_version("INLA", version="23.05.30",repos=c(getOption("repos"),INLA="https://inla.r-inla-download.org/R/testing"), dep=TRUE)
Trying https://cloud.r-project.org
Trying https://inla.r-inla-download.org/R/testing
Error in download_version_url(package, version, repos, type) :
version '23.05.30' is invalid for package 'INLA'
and for R 4.4, since remotes::install_version has default type='source'
that can't be changed to binary, we get the familiar error:-
> remotes::install_version("INLA", version="24.05.10",repos=c(getOption("repos"), INLA="https://inla.r-inla-download.org/R/testing"), dep=TRUE)
Downloading package from url: https://inla.r-inla-download.org/R/testing/src/contrib/INLA_24.05.10.tar.gz
Installing package into ‘C:/Users/wrh1/Documents/R/win-library/4.4’
(as ‘lib’ is unspecified)
* installing *binary* package 'INLA' ...
C:\Windows\cp.exe: invalid option -- )
Try `C:\Windows\cp.exe --help' for more information.
ERROR: installing binary package failed
Incidentally, for R 4.3 the issue is that version 23.05.30 doesn't exist - the earliest is 23.05.30-1 - and the most recent 24.05.01-1 - but again, you can't install any of these with remotes::install_version because that would require compilation from source. (I haven't tested R 4.1)
So at present, the only way you can install any INLA package on any R version on windows is
install.packages("INLA",repos=c(getOption("repos"),INLA="https://inla.r-inla-download.org/R/stable"), dep=TRUE, type="binary")
which will get the most recent binary for your R version. There is no way I think to get a specific older (binary) version, or to use any method that involves compiling from source.
There's always a way: downloading the needed tar/zip file manually and installing from the file instead of the repository. But the type="binary"
option is easier.
If we try and build INLA from source, we get the error message below:-
This is easy to work around with R 4.4 - just don't build from source, and the binary gets downloaded - if the ready-build version is available. But for users still on R 4.3, there is no matching binary of 24.05.10 in
https://inla.r-inla-download.org/R/stable/bin/windows/contrib/4.3/
, so install.packages tries to build 24.05.10 from source. They have to either upgrade to R 4.4, or specify version 24.05.01-1 manually, because there's a binary for that.So the workarounds are not hard, but is seems there's a problem in the source version for building at the moment.