I'd like to follow up on our discussion at https://github.com/r-lib/remotes/issues/790 and suggest some new functionalities for the pkg_deps. These would greatly help our enterprise use and allow us to migrate from the remotes package.
Make pkg_deps display all dependencies regardless of remotes sources. Currently, if a remote source is specified, it overwrites the version available in repos if it exists. We suggest a parameter (or even default behaviour) that allows us to keep both - the version identified in remotes and the one from repos. In our enterprise application, depending on the stage and dependency type, we want to either include or exclude remote sources, so having them both in the data.frame would allow us to implement dynamic filters on our own and build them on top of the pak. The same could be applied to supplied repositories (and, by extension, Additional_repositoires provided we use the source package). If a package is available in multiple repositories, it would be great if the data.frame had a different row for each latest version and repository pair. Again, bringing our needs into context, we need to filter packages available in multiple repositories based on some conditions (like the order of repos, similar to the package search path). Similar to remotes packges request, had we had all these versions in the data.frame, we could start from there and build our installation (filtering) mechanism based on that.
Implement something similar to remotes:::update.package_deps(). Bascially a function which would accept a subset of rows from the pkg_deps data frame and install the specified package.
Please, let me know what you think about these suggestions and whether you see them as part of the pak package in the future. :)
Hi all
I'd like to follow up on our discussion at https://github.com/r-lib/remotes/issues/790 and suggest some new functionalities for the
pkg_deps
. These would greatly help our enterprise use and allow us to migrate from theremotes
package.pkg_deps
display all dependencies regardless of remotes sources. Currently, if a remote source is specified, it overwrites the version available inrepos
if it exists. We suggest a parameter (or even default behaviour) that allows us to keep both - the version identified in remotes and the one from repos. In our enterprise application, depending on the stage and dependency type, we want to either include or exclude remote sources, so having them both in the data.frame would allow us to implement dynamic filters on our own and build them on top of thepak
. The same could be applied to supplied repositories (and, by extension,Additional_repositoires
provided we use the source package). If a package is available in multiple repositories, it would be great if the data.frame had a different row for each latest version and repository pair. Again, bringing our needs into context, we need to filter packages available in multiple repositories based on some conditions (like the order of repos, similar to the package search path). Similar to remotes packges request, had we had all these versions in the data.frame, we could start from there and build our installation (filtering) mechanism based on that.remotes:::update.package_deps()
. Bascially a function which would accept a subset of rows from thepkg_deps
data frame and install the specified package.Please, let me know what you think about these suggestions and whether you see them as part of the
pak
package in the future. :)