Open klmr opened 1 year ago
There isn't, and it is unlikely that we'll add it to remotes, as we are rather focusing on improving pak.
we are rather focusing on improving pak
I fully support this! Should I re-raise the issue for ‘pak’ or ‘pkgdepends’ then?
That said, as far as I understand there are still several other packages (e.g. ‘devtools’, ‘renv’ …?) that either rely on ‘remotes’ or explicit reference it to install packages based on the DESCRIPTION
Remotes
declaration. Are there plans to port these to use ‘pak’/‘pkgdepends’ in the future? And will ‘pak’ depend on ‘pkgdepends’?
devtools will depend on pak eventually.
renv does not use remotes.
pak already contains on pkgdepends.
renv does not use remotes.
No, but its implementation (linked above) explicitly references the ’remotes’ documentation for the Remotes
field. I’m just wondering whether ‘renv’ will continue to have its own implementation of remotes parsing (and, if so, which specification it will in the future reference) or whether it will depend on/vendor ‘pak’ or ‘pkgdepends’. Having this (fairly complex) specification implemented independently (and unavoidably ultimately inconsistently!) in different packages doesn’t strike me as ideal.
I’m referring to the
DESCRIPTION
Remotes
field dependency types. I can see remote types for Git, URL, local, etc. But nothing for a non-CRAN, CRAN-like repository, such as R-Universe (or hosted, private instances of package repositories). Does something like this exist?I know that I can get the same functionality by instead using a project-level
.Rprofile
file in the relevant package project, and addingoptions(repos = c(getOption('repos'), my_repo = "url_here"))
. But I quite like the declarative style of having this in the packageDESCRIPTION
instead.I’m imagining something like the following: