Allow reference to specific repo for pkg_install

[mjkanji]

I have the same issue as #357 and while the comment there does fix the problem, I'd like to suggest an enhancement whereby one of the non-standard repos can actually be specified for a given package.

In my case, I want to install just one package using a snapshot from RSPM, but I want to install all other packages using the default CRAN repo. I guess I could just overwrite options(repos = c(CRAN = "...") before and after that one package is installed, but it would be great if I could just do something like

repo_add(dplyr100 = "[email protected]")
repo_add(stor352 = "[email protected]")

pkg_install(c(
  "cran::remotes",
  "dplyr100::dplyr",
  "stor352::AzureStor"
))

[gaborcsardi]

Where are the dependencies supposed to be installed in this case?

[mjkanji]

I'm not sure I understand the question. I'm admittedly not very familiar with how dependency solvers in general or how pak internals works, but I was assuming that the above would be translated into something like

library(pak)
library(devtools)

dplyr100 = repo_resolve("[email protected]")
stor352 = repo_resolve("[email protected]")

install.packages("remotes", repos = "https://cloud.r-project.org")
install_version("dplyr", version = NULL, repos = dplyr100)
install_version("AzureStor", version = NULL, repos = stor352)

Of course, this is just a functional example of what I was hoping happens and the installs are sequential and not in one go, as in my first example. I know there's all the dependency solving that needs to happen in the middle that I'm not really addressing.

Is your concern that, say, AzureStor and remotes might have the same dependency (pkgX) and so whether pkgX should be downloaded from the RSPM snapshot (stor352) or the default CRAN repo?

I realise now that mixing and matching here could potentially lead to conflicts (say we install the latest version of pkgX from the default CRAN repo, but it has a breaking change from the version that AzureStor's older version is expecting and so AzureStor stops working).

Not sure if the above problem is unsolvable and so my request impossible to implement.

[gaborcsardi]

If you write

pkg_install("dplyr100::dplyr")

and dplyr depends on vctrs, where should be vctrs installed from? Wherever?

[mjkanji]

If you write

pkg_install("dplyr100::dplyr")

and dplyr depends on vctrs, where should be vctrs installed from? Wherever?

I guess this is where we start to go out of my depth, but presumably, if vctrs is not already installed, you'd look for vctrs in the same repo (dplyr100). In RSPM's case, the repos are snapshots of all of CRAN (if I'm not mistaken), so it should be able to find a corresponding version of vctrs.

If vctrs is already installed, then I guess we have a potential conflict with dplyr expecting an older version of vctrs so we potentially have to downgrade but I'm not experienced enough in this realm to know what the best practices are (e.g., we could just leave the newer version installed, on the assumption that there are no breaking changes).

Alternatively, if the repo is not RSPM and is maybe a private repo for just one package, then it obviously won't be able to find vctrs in the same repo and in that case, we'd revert back to CRAN to find the relevant dependency?

Perhaps these can be interactive decisions for the user to make?

Or instead of specifying the repo, it'd be easier to implement what I'm suggesting with the ability to specify the version (I see this was previously discussed in #122), and if the specified version is older than the latest, then pak automatically queries, say, RSPM for the older snapshot?

Again, though, this is out of my depth so not sure if my suggestions are entirely unfeasible/ignorant.

[gaborcsardi]

I think we would like to have a way to select specific repos for packages at some point, even though it is not easy to have a nice concise notation.