Nicer adding/installations of github repositories

[gwangjinkim]

A package manager from Common Lisp, roswell, uses the syntax:

ros install githubaccount/githubrepo

and installs then automatically from github.

With time I really love this feature. And I am pretty sure, that people will love it. It is super convenitent.

rv add githubaccount/githubrepo

Instead of

rv add package --git https://github.com/githubaccount/githubrepo --commit 223423

Something like:

rv add <repo-spec>...

<repo-spec> :=
  <owner>/<repo> [ "@" <ref> ] [ ":" <subdir> ]
| <git-url>        [ "@" <ref> ] [ ":" <subdir> ]

<ref> := <branch> | <tag> | <commit-sha>
<subdir> := path/inside/repo

resulting in:

# default branch
rv add tidyverse/dplyr

# branch
rv add tidyverse/dplyr@main
rv add tidyverse/dplyr@feature/new-api

# tag
rv add r-lib/cli@v3.6.2

# commit SHA
rv add r-lib/rlang@9a8c5d2

# repo with package living in a subdir
rv add r-lib/usethis@v2.2.3:r-package

# full git URL (https or ssh) also works
rv add https://github.com/r-lib/cli.git@v3.6.2
rv add git@github.com:r-lib/cli.git@v3.6.2

or explicit ref prefixes:

@branch:<name>
@tag:<tag>
@commit:<sha>

used like:

rv add r-lib/cli@tag:v3.6.2
rv add r-lib/cli@branch:main
rv add r-lib/cli@commit:9a8c5d2

As syntactic sugar? And keeping the CLI flags as fallback?

[gwangjinkim]

This might be related to #238

It would be also nice to be able to just do:

rv add bioconductorpackage

And configure somehwere whether rv should first look at CRAN or bioconductor (precedence).
With a corresponding entry into rproject.toml and rv.lock.

[gwangjinkim]

From my experience in Common Lisp, the ease of package access - be it from github or the main repos - in Roswell -
makes me use it preferably.

So adding these features to rv will definitely draw more users to rv instead of renv, rix, rig, etc.

To #397 : the rig team didn't show any interest in making unpriviledged R installations, so this would definitely drive users away from rig.

rix's weakness is: The interface is not easy (one has unintuitively - first use any R version to install rix, then from inside the R terminal, using the rix package generate a .nix file with the packages. And so on, and so on.
The biggest weakness, however, was: Not all packages were easily available from the nix repositories. Maybe because the community is too small. In this renv was definitely better covered.

[dpastoor]

I agree that there is some ergonomic wins to be had - @JosiahParry has also articulated it a bit around how we manage the config file.

I am more willing to entertain adding this - in particular because we do already parse all those patterns in description file remotes to derive what we need, so this would not be a big lift. To add this we would also need to add, from "day1" the ability to control the default url when a git-like path is provided, because for the enterprise groups we are supporting, many do not support github.com as a default, so giving them a way to override that strategy and point to their stuff at least by default will be important.