search

krlmlr / r-appveyor

Tools for using R with AppVeyor (https://appveyor.com)
132 stars 60 forks source link

Unavailable packages causing build failure #57

Closed cdeterman closed 8 years ago

cdeterman commented 8 years ago

I have had several builds successfully complete previously but suddenly my build is failing complaining about packages not available.

The build page is here

with the relevant lines:

Packages required but not available: 'Rcpp' 'assertive' 'RcppEigen' 'BH' Package suggested but not available: 'knitr'

Clearly, these packages should be available as they are all used commonly.

krlmlr commented 8 years ago

I'm aware of this, I believe this is because https://cran.r-project.org/bin/windows/contrib/3.4/ is unavailable. Not much I can do about it, but you might ask CRAN.

Try switching to R-stable or R-patched for the time being.

krlmlr commented 8 years ago

Actually, it's not CRAN but R-devel who should be consulted for this (R-devel is R 3.3.0, it's dubious why it's accessing the 3.4 path).

jimhester commented 8 years ago

@krlmlr R-devel has been bumped to R 3.4 as of r70342

krlmlr commented 8 years ago

Oh, I see. Then it's dubious why R-devel is 3.4.0... What's 3.3.x then?

cdeterman commented 8 years ago

This seems to get part of the way there but now the devtools installation appears to be failing as the dependencies httr, jsonlite, mime, curl, openssl fail to install. You can see example here.

krlmlr commented 8 years ago

@jeroenooms: Is the 3.3.0/3.4.0 confusion due to the new toolchain? I guess it would be safest to default to R-patched for now...

jaredhuling commented 8 years ago

This issue is still a problem and the suggested fixes by krlmlr do not work

krlmlr commented 8 years ago

@jaredhuling: Could you point me to a failing build?

jaredhuling commented 8 years ago

I should have done that initially. Here it is: https://ci.appveyor.com/project/jaredhuling/oem/build/job/j87ik7jmwh532cw4

krlmlr commented 8 years ago

Does it work if you add RcppEigen to the "Imports" of your package?

krlmlr commented 8 years ago

Oh, it looks like RcppEigen only has 64-bit libraries. Could you the following setting in appveyor.yml:

environment:
  global:
    WARNINGS_ARE_ERRORS: 1

  matrix:
  - R_VERSION: stable
    R_ARCH: x64

See also https://github.com/krlmlr/r-appveyor/blob/7ed23f263873ba51d394b5d2cd5ce451b6c80acf/appveyor.yml#L34 and the surrounding lines.

Could https://github.com/RcppCore/RcppEigen/issues/34 be related?

eddelbuettel commented 8 years ago

We do not yet know what https://github.com/RcppCore/RcppEigen/issues/34 actually is as it, not unlike Nessy, has only been spotted in one habitat, the Dortmund CRAN builder. Which has nothing to do with appveyor. So I'd suggest that it may be best not to refer to it at this point.

krlmlr commented 8 years ago

@eddelbuettel: Thanks for chiming in. I only observe that RcppEigen_0.3.2.8.1.zip downloaded from CRAN doesn't have a "libs/i386" directory.

jaredhuling commented 8 years ago

@krlmlr setting to x64 fixed the issue. Thanks

wlandau commented 6 years ago

I am currently having a similar issue where the unavailability of graph (through Bioconductor) causes the failure. A couple strange things about that particular failure:

  1. WARNINGS_ARE_ERRORS was not set, yet the error message begins with "Error (converted from warning)".
  2. graph was only included in the installation because it is a dependency of CodeDepends, which is only a "Suggests" package. drake and its tests are ready for CodeDepends to be absent, and I strongly prefer that AppVeyor just roll with it if graph cannot be installed.
gaborcsardi commented 6 years ago
  1. is because of an update to the remotes package, which errors on warnings now, unless an env var is set. (see the remotes README).

So if you set the env var, your build will continue.

@krlmlr maybe you want to set this by default?

cc @jimhester

wlandau commented 6 years ago

Thanks, @gaborcsardi! A newer build is continuing as desired. For anyone looking on, I glanced here and set R_REMOTES_NO_ERRORS_FROM_WARNINGS to true here in appveyor.yml.

krlmlr commented 6 years ago

Thanks. I'd rather keep the defaults lean, but let's watch how this evolves.

Maybe just add support for multiple CRAN-like repos, so that graph and others can be installed automatically? Alternatively, you could use r_install_bioc to install manually: https://github.com/krlmlr/r-appveyor/blob/2ba367db9ac2550127d4e05f64d9c3ffe824e5fc/r-travis/scripts/travis-tool.sh#L368

jeroen commented 6 years ago

You can also setRepositories(ind = 1:4) before building so that bioc dependencies are automatically available.

wlandau commented 6 years ago

Thanks @krlmlr and @jeroen. I may come back to your suggestions depending on how https://github.com/ropensci/drake/issues/41 plays out.

Come to think of it, drake's AppVeyor builds requiring graph were actually working until late last night. I see that graph version 1.58.2 was released recently, so I guess it may have taken some time for the Windows builds to show up on Bioconductor. I like the env var solution because drake has 26 "Suggests" packages, and except for 2 or 3 of those, I just skip the affected tests when they are not installed.

LiNk-NY commented 6 years ago

Hi all, Please look into using BiocManager::repositories() and also #125 Thanks.

krlmlr commented 6 years ago

Thanks. Can someone please open a new issue for discussing integration of BioConductor?