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

Dependencies of non-available packages #14

Closed
Enchufa2 opened this issue Aug 12, 2020 · 2 comments
Closed

Dependencies of non-available packages #14

Enchufa2 opened this issue Aug 12, 2020 · 2 comments

Comments

@Enchufa2
Copy link
Member

Suppose that a user wants to install.packages(c("pkgA", "pkgB")) (with bspm enabled). Suppose that pkgA is provided in the system repos and has zero dependencies; pkgB is not provided in the system repos and depends on pkgC, which is available in the system repos. @eddelbuettel what would you expect?

  1. pkgA is installed from system repos. pkgB and pkgC are installed from CRAN (current behaviour).
  2. pkgA and pkgC are installed from system repos. pkgB is installed from CRAN.
  3. (1) by default, but (2) if enabled via options.
  4. (2) by default, but (1) if disabled via options.
@eddelbuettel
Copy link
Contributor

eddelbuettel commented Aug 12, 2020

I think one of the strengths of the current design is that it does not reinvent install.packages() but dispatches to it. So my recommendation is to keep it simple and rely as much as you can on R. And I don't even really know what R does in the case of mixed binary and source (as I almost always rely / have relied on source) -- I guess it blends as well.

RSPM appears to fall back to 'compiling from source' for binaries it does not have, which is twice as bad because presumably it does not have them for lack of easy building so by then calling for a build from source it sets it up for a fail in all cases I encountered so far (in Docker settings).

@Enchufa2
Copy link
Member Author

I think current behaviour is ok, but I'm probably too biased because I programmed it.

Above I was specifically thinking about something like pkgA=errors, pkgB=simmer, pkgC=Rcpp. The call to bspm::install_sys would install errors and return simmer. Then R would install Rcpp first and then simmer. Option (2) above would extract simmer dependencies and perform a second bspm pass with them, and so Rcpp would get installed from system. Then R would see that Rcpp is already satisfied and install only simmer. But this obviously generates other problems. For example, if the installation of simmer from source fails, then the user gets Rcpp anyway (this is a bad example, because Rcpp would be for sure useful for many other packages, but you get the point).

I was considering (3) if your expectations differed a bit and (2) or (4) only if they differed a lot with my (probably biased) expectations. But if not, it's ok as it is.

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