Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ci] fall back to source installs of R packages if binary missing (fixes #3875) #3876

Merged
merged 6 commits into from
Jan 28, 2021

Conversation

jameslamb
Copy link
Collaborator

I believe this will fix #3875. Right now in the Mac CI jobs for the R package, we set type = "binary" in install.packages(). This can lead to failures shortly after a new package needed in those jobs is uploaded to CRAN, when only source versions are available. Precompiled binaries from CRAN usually take 1-2 days to become available, in my experience.

the package {withr} was updated yesterday (https://cran.r-project.org/web/packages/withr/index.html), and I think the failures observed in #3875 happened because of this phenomenon.

This PR changes the strategy for installation on Mac to "both". From ?install.packages

An alternative (and the current default) is "both" which means ‘use binary if available and current, otherwise try source’. The action if there are source packages which are preferred but may contain code which needs to be compiled is controlled by getOption("install.packages.compile.from.source"). type = "both" will be silently changed to "binary" if either contriburl or available is specified.

So as of this PR, Mac builds will look for binaries (which are faster to install), but will install source packages from CRAN if the source package is newer.

This should prevent future issues like this from blocking LightGBM's CI.

@@ -101,9 +101,9 @@ fi
# to avoid a CI-time dependency on devtools (for devtools::install_deps())
packages="c('data.table', 'jsonlite', 'Matrix', 'R6', 'testthat')"
if [[ $OS_NAME == "macos" ]]; then
packages+=", type = 'binary'"
packages+=", type = 'both'"
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as a reminder, this flag cannot be used on Linux, and that's why it's in this if.

From inside a rocker/verse container:

> install.packages("jsonlite", type = "both")
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
Error in install.packages("jsonlite", type = "both") : 
  type == "both" can only be used on Windows or a CRAN build for macOS

Copy link
Collaborator

@StrikerRUS StrikerRUS left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Many thanks!

@jameslamb
Copy link
Collaborator Author

@StrikerRUS we'll have to use admin rights to merge this, since I haven't fixed #3873 yet. Is that ok?

Otherwise I can remove the linting job temporarily from all-successful in the GitHub Actions config, then put it back in the fix for #3873

@StrikerRUS
Copy link
Collaborator

@jameslamb

we'll have to use admin rights to merge this,

And this one #3874 to fix CUDA tests.

I think admin rights is better than mess in CI code between PRs.

@StrikerRUS
Copy link
Collaborator

I see in macOS R4:

 Error in loadNamespace(name) : there is no package called 'withr'
  Calls: test_check ... loadNamespace -> withRestarts -> withOneRestart -> doWithOneRestart
  Execution halted

Seems having both is not enough.

@jameslamb
Copy link
Collaborator Author

I see in macOS R4:

 Error in loadNamespace(name) : there is no package called 'withr'
  Calls: test_check ... loadNamespace -> withRestarts -> withOneRestart -> doWithOneRestart
  Execution halted

Seems having both is not enough.

ok seeing that, now I think the issue is that something somewhere in {testthat}'s many recursive dependencies (it was more than 100, the last time I checked), needs {withr} but didn't correctly specify it in their metadata. I can just add an install.packages("withr") to try to fix it.

I still think the "both" fix is a good one and will also improve stability, even if it didn't end up fixing this specific issue.

@jameslamb
Copy link
Collaborator Author

hmmmm interestingly, it DOES look like R tried to install {withr} (https://github.com/microsoft/LightGBM/pull/3876/checks?check_run_id=1785068087).

trying URL 'https://cloud.r-project.org/bin/macosx/contrib/4.0/withr_2.4.1.tgz'
Error in download.file(url, destfile, method, mode = "wb", ...) :
cannot open URL 'https://cloud.r-project.org/bin/macosx/contrib/4.0/withr_2.4.1.tgz'
In addition: Warning message:
In download.file(url, destfile, method, mode = "wb", ...) :
cannot open URL 'https://cloud.r-project.org/bin/macosx/contrib/4.0/withr_2.4.1.tgz': HTTP status was '404 Not Found'
Warning in download.packages(pkgs, destdir = tmpd, available = available, :
download of package ‘withr’ failed
trying URL 'https://cloud.r-project.org/bin/macosx/contrib/4.0/data.table_1.13.6.tgz'
Content type 'application/x-gzip' length 2335683 bytes (2.2 MB)

But it still only looked for the binary. Ok, let me experiment a little. I commented out all other CIs so I don't hurt our capacity too much while testing.

@jameslamb
Copy link
Collaborator Author

I think admin rights is better than mess in CI code between PRs.

I agree!

@jameslamb
Copy link
Collaborator Author

Ah!!! I can see on CRAN that the {withr} r-release binaries exist, but for 2.4.0 only (the package is on 2.4.1). This is why the builds are only failing for R 4.x and not R 3.6.

image

I think R is getting confused by this.

No amount of trickery with install.packages() can fix this and still preserve our binary installs, I don't think. So I guess we do have to add a separate installation of {withr}, from source, to resolve this.

@StrikerRUS
Copy link
Collaborator

@jameslamb

So I guess we do have to add a separate installation of {withr}, from source, to resolve this.

This will be reverted after a day or two, right? When version will be in a sync state at CRAN, I mean.

@jameslamb
Copy link
Collaborator Author

It probably could be reverted, yes. I don't know a more permanent fix for this problem :/

type = "both" is supposed to exactly solve this problem, but it looks like it isn't.

@jameslamb
Copy link
Collaborator Author

@jameslamb
Copy link
Collaborator Author

#3874 and #3877 have been merged into master and I've merged master into this PR, so all CI jobs should now pass on this PR

@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 24, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

macOS CI R jobs fail
2 participants