Another "unable to access index for repository" set of failures, for devel version which I guess bumped to 4.0?

[Alex F. Bokov, Ph.D.]

We are having build failures for the devel version...

Installing package into 'c:/RLibrary'
(as 'lib' is unspecified)
Warning: unable to access index for repository https://cloud.r-project.org/bin/windows/contrib/4.0:
  cannot open URL 'https://cloud.r-project.org/bin/windows/contrib/4.0/PACKAGES'
   package 'remotes' is available as a source package but not as a binary

Further down we see...

remotes::install_deps(dependencies = TRUE, type="win.binary")'
Skipping 22 packages not available: bit64, clipr, csvy, curl, data.table, feather, fst, haven, hexView, jsonlite, knitr, magrittr, openxlsx, pzfx, readODS, readr, readxl, rmatio, testthat, tibble, xml2, yaml

...and finally it fails due to missing packages:

Packages required but not available:
  'haven', 'curl', 'data.table', 'readxl', 'openxlsx', 'tibble'
Packages suggested but not available:
  'bit64', 'testthat', 'knitr', 'magrittr', 'clipr', 'csvy', 'feather',
  'fst', 'hexView', 'jsonlite', 'pzfx', 'readODS', 'readr', 'rmatio',
  'xml2', 'yaml'
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.
See section 'The DESCRIPTION file' in the 'Writing R Extensions'
manual.
* DONE
Status: 1 ERROR
See
  'C:/projects/rio/rio.Rcheck/00check.log'
for details.
Command exited with code 1
7z a failure.zip *.Rcheck\*

Thanks.

[Kirill Müller]

It looks like CRAN doesn't have all packages in the 4.0 version yet. Can you install from source for now?

[Alex F. Bokov, Ph.D.]

I tried, but I guess I wasn't doing it right? Below is the appveyor.yml file I'm using.

Appveyor fails on R_VERSION: devel, so I added the PKGTYPE: both directive, and it is still trying to install binary versions and still failing to find 22 of the libraries.

Is there some directive that would make Appveyor look in https://cloud.r-project.org/bin/windows/contrib/r-devel/ instead of in a specific version? Because in r-devel I see those missing binary packages.

appveyor.yml

# Download script file from GitHub
init:
  ps: |
        $ErrorActionPreference = "Stop"
        Invoke-WebRequest http://raw.github.com/krlmlr/r-appveyor/master/scripts/appveyor-tool.ps1 -OutFile "..\appveyor-tool.ps1"
        Import-Module '..\appveyor-tool.ps1'
install:

ps: Bootstrap
environment:

global:

WARNINGS_ARE_ERRORS: 1

USE_RTOOLS: true
matrix:


R_VERSION: release

R_ARCH: x64


R_VERSION: oldrel

RTOOLS_VERSION: 33

CRAN: http://cran.rstudio.com


R_VERSION: devel

R_ARCH: x64

GCC_PATH: mingw_64

PKGTYPE: both


R_VERSION: devel

GCC_PATH: mingw_32


matrix:

fast_finish: true
build_script:

travis-tool.sh install_deps

test_script:

travis-tool.sh run_tests

on_failure:

7z a failure.zip *.Rcheck*
appveyor PushArtifact failure.zip

artifacts:


path: '.Rcheck**.log'

name: Logs


path: '.Rcheck**.out'

name: Logs


path: '.Rcheck**.fail'

name: Logs


path: '.Rcheck**.Rout'

name: Logs


path: '*_*.tar.gz'

name: Bits


path: '*_*.zip'

name: Bits

[Kirill Müller]

Can you try PKGTYPE: source ?

It would be great if R-devel looked in .../r-devel -- I guess the most sustainable way to achieve this would be a patch to R-core to fix contrib.url() .

[Alex F. Bokov, Ph.D.]

I'll try it and report back. Is there a way to make it conditional? I.e. only trying source packages only when the binary versions are not found?

[Alex F. Bokov, Ph.D.]

Yes! It works, though very slow build-times.

I thought both would fall back on src if it couldn't find binaries, but it was looking at only the binaries and failing. Is there a setting that does result in this behavior?

Thanks for your help.

[Indrajeet Patil]

Same as #166

[Alex F. Bokov, Ph.D.]

Let's brainstorm some options besides setting PKGTYPE: source and slowing down every build affected by this problem (since the affected packages include magrittr, curl, data.table, knitr, readr, testthat, and tibble I'm surprised that @IndrajeetPatil and I are the only ones commenting on this).

1. To @krlmlr 's suggestion of submitting a feature request for contrib.url() upstream to R-Core, it looks like there has been a similar issue open since May 2018, I don't see any responses or updates. Anybody know if that's the correct channel for the utils core package?
2. I can't even find who is the official POC for CRAN repos. By the nature of your project I wonder, @krlmlr or @craigcitro if you have any experience on how to best approach them, and whom to approach, for an ETA of what should be a simple fix on their end for a problem that is currently breaking or slowing down other packages' builds?
3. Let's say it turns out to be the scenario of us being on our own and not being able to rely on a timely fix to either contrib.url() nor to CRAN. Since this is a problem that seems like it could recur with any new R release, would you be open to a workaround at the r-appveyor level? What kinds of workarounds would make the most sense? A forked and patched version of remotes? A custom replacement for just the install_deps() function? I've just started using Appveyor to test R code, but I am happy to help to the best of my abilities.

Thanks.

[Indrajeet Patil]

This should be resolved now since R core has officially changed the URL for R-devel version to:
https://cloud.r-project.org/bin/windows/contrib/4.0/PACKAGES

[Alex F. Bokov, Ph.D.]

Yes, thanks. I tried re running old failed builds and they seem to be working again.

So the immediate problem has gone away for a while but I'm wondering if anybody would be interested in brainstorming how we can prevent the next R version upgrade from shutting us down again?