r-lib / remotes

Install R packages from GitHub, GitLab, Bitbucket, git, svn repositories, URLs
https://remotes.r-lib.org/
Other
330 stars 152 forks source link

Is there a remote type for CRAN-like repositories? #737

Open klmr opened 1 year ago

klmr commented 1 year ago

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 adding options(repos = c(getOption('repos'), my_repo = "url_here")). But I quite like the declarative style of having this in the package DESCRIPTION instead.

I’m imagining something like the following:

Remotes:
    repo::https://foo.r-universe.dev:pkg1,
    repo::https://private.corporate.ns:pkg2
gaborcsardi commented 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.

klmr commented 1 year ago

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’?

gaborcsardi commented 1 year ago

devtools will depend on pak eventually.

renv does not use remotes.

pak already contains on pkgdepends.

klmr commented 1 year ago

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.