Add remote_precedence parameter to dev_package_deps

[maksymiuks]

As discussed in the https://github.com/r-lib/remotes/issues/732 it's a PR with suggested implementation.

[gaborcsardi]

Thanks! Hmmm, does this really help people install a package with the CRAN dependencies? How would one do that?

[maksymiuks]

If this change gets merged, I will be able to run:

path <- "path_to_pkg_root"
deps_to_install <- remotes::dev_package_deps(path, dependencies = TRUE, remote_precedence = FALSE)
update(deps_to_install)

and be sure that only CRAN versions were installed (updated) disregarding what is specified in the remotes. Particularly useful if we put hard dependencies in remotes to address some new features not yet on github but in the meantime still have a build for CRAN version only, then we can just change the value of the parameter and install dependencies without remotes masking dependencies existing on CRAN. It a nutshell, it will be helpful in any case when for some reason we need to update our dependencies to the version available on CRAN, disregarding remotes if possible.

[gaborcsardi]

it will be helpful in any case when for some reason we need to update our dependencies to the version available on CRAN, disregarding remotes if possible.

Well, except that if the non-CRAN version is already installed, then it will not "update" that to the CRAN version, right?

[maksymiuks]

I agree word "update" wasn't really a fortunate one. You are right, if the developer stores everything in one library then yes it won't be updated, as probably remote is ahead of CRAN so it will be skipped by the design of this function. But if one has isolated libraries for testing and properly sets the search path, or if it's a ci/cd scenario, it will do its job as the update is a very neat feature for installing the package's dependencies in a controlled way.

[gaborcsardi]

Thanks!