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

Don't allow remotes::install_github() to convert warnings to errors on unavailable PACKAGES file #38

Open
mtmorgan opened this issue Jan 19, 2019 · 1 comment

Comments

@mtmorgan
Copy link
Collaborator

mtmorgan commented Jan 19, 2019

remotes::install_github() converts warnings about dependencies that cannot be installed (e.g., because of missing binaries) into errors. This is different from the install.packages() behavior in non-github installations by BiocManager.

This can be made consistent by setting an environment variable Sys.setenv(R_REMOTES_NO_ERRORS_FROM_WARNINGS, FALSE) prior to calling remotes::install_github().

Is this a good idea?

Actually, the use case is that the PACKAGES index isn't available for all types of packages, even though the package of interest is not found in the repository where PACKAGES does not exist.

See https://stat.ethz.ch/pipermail/bioc-devel/2019-January/014560.html

@seandavi

@mtmorgan mtmorgan changed the title Don't allow remotes::install_github() to convert warnings to errors on unavailable packages Don't allow remotes::install_github() to convert warnings to errors on unavailable PACKAGES file Jan 19, 2019
@seandavi
Copy link

Having the user (me) set the environment variable seems like a reasonable compromise. I haven't thought through all the ramifications of setting it in BiocManager::install.

After CRAN binaries for Mac become available, this will be a moot point, anyway, at least for the case I mentioned in the email.

Just a note that the incantation is, I think:

Sys.setenv("R_REMOTES_NO_ERRORS_FROM_WARNINGS"=TRUE)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants