Let install_version() search for version in multiple repos

[kenahoo]

TL;DR: I would like to change install_version() so that it will search for the requested version of the package in each of the repositories given, in sequence.

Motivation: my company uses R internally, creating packages for various projects and publishing them to internal CRAN-alike servers for integration by other teams. We have one “cran-stable” for official releases, and one CRAN-alike that updates with new snapshots every time someone pushes to a “develop” branch.

I would like our team to call install_version(pkg, version, repos), which then iterates over each entry of repos until a suitable version is found.

For instance, we might have the following:

• http://myserver/cran-stable:
• MyPackage_0.23.tar.gz
• http://myserver/cran-dev:
• MyPackage_0.24-283.tar.gz

repos <- c(Stable="http://myserver/cran-stable",
              Dev="http://myserver/cran-dev",
             CRAN="https://cran.revolutionanalytics.com")
install_version('MyPackage', '0.23', repos)  # Installs from ‘Stable’
install_version('MyPackage', '0.24', repos)  # Installs from ‘Dev’

Right now, it looks like install_version() expects exactly one version of a package to be officially published across all repositories, and it only knows how to look for alternate versions in archive/ directories, under the assumption that the only alternate versions that could exist are previously-published versions.

Also, because packages in the “Dev” server may have versioned dependencies on packages from either repository, the same semantics would need to apply to the dependencies too, so install_version() would call itself recursively to handle them.

I would be happy to work this up as a pull request that keeps the existing semantics of finding packages in archive/ directories too.

[kenahoo]

Looking closer at install_version(), it looks like the version argument is an exact version required, not a minimum version. So my example above would need to be:

repos <- c(Stable="http://myserver/cran-stable",
              Dev="http://myserver/cran-dev",
             CRAN="https://cran.revolutionanalytics.com")
install_version('MyPackage', '>= 0.23', repos)  # Installs from ‘Stable’
install_version('MyPackage', '>= 0.24', repos)  # Installs from ‘Dev’

and the version field would be extended to take a specification like the Depends: and Imports: fields in a DESCRIPTION file (and like those, multiple specs could be provided to be 'and'-ed together).

[jimhester]

Why can't you use install.packages() directly and adjust the repos option depending on whether you want to install from the stable or development branch? If you want to make this easy to switch just write a simple function to change the repos option.

use_devel <- function(devel = TRUE) {
  repos <- getOption("repos")
  if (isTRUE(devel)) {
    repos["Dev"] <- "http://myserver/cran-dev"
  } else {
    repos <- repos[names(repos) != "Dev"]
  }
  options(repos = repos)
}

[kenahoo]

That doesn't work because dev packages can depend on prod packages.

[jimhester]

'prod' packages would still be available using install.packages(), just set options(repos = c(Stable = "Stable="http://myserver/cran-stable", CRAN="https://cran.revolutionanalytics.com")) in your personal or site .Rprofile.

[kenahoo]

Here's a scenario where that doesn't work:

  Repo-Stable:
    Package A, version 1.2; depends on B (>= 1.0)
    Package B, version 1.4

  Repo-Dev:
    Package A, version 1.3-415; depends on B (>= 1.0)
    Package B, version 1.5-31

If I want to install the 'dev' version of A, then your suggestion would be to call install.packages('A', repos=c(repo.dev, repo.stable)). But that would install B 1.5-31 as a prereq, even though the stable one satisfies the dependency.

In a nutshell, wanting the dev version of a specific package doesn't mean I want the dev version of all the other packages too. If we could make my proposed change to install_version, then the order of repos would indicate the caller's policy (which would usually be "prefer stable packages to dev packages" but might be the other way around; it could also be "prefer our local repo to a remote CRAN repo but fall back if necessary").

Your suggestion of tweaking options('repos') is exactly what we've been doing around here for a long time, but it's gotten extremely fiddly and annoying. It basically makes the developer manually check & satisfy all dependencies up & down the tree, by hand. In contrast, the Java developers in our office just tell Maven which version of which artifact they want, and which repositories can provide it, and Maven just figures everything out, which is what I'm hoping devtools can help with in a similar way.

[kenahoo]

Here's my forkbranch where I'm working on this: https://github.com/kenahoo/devtools/commits/install_version-multi

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/