New feature idea: Install from Zenodo

[nuest]

I am wondering if you would consider a function remotes::install_zenodo(doi = "10.5281/zenodo.2528500") for downloading and installing a package from Zenodo a function fitting this package.

---

How could this function work?

The implementation would not rely on the git protocol, but could use the Zenodo API to download the archive of an R package (the zen4R package might have some useful bits but it is not a feasible dependency for remotes). When using the GitHub - Zenodo - integration, the Zenodo record contains a single zip file with the GitHub repository's source code. Two examples (found by searching for "CRAN" on Zenodo):

• https://zenodo.org/record/2528500
• https://zenodo.org/record/55336

In addition to the DOI, plain Zenodo URLs and DOI URLs could be supported, too:

remotes::install_zenodo("10.5281/zenodo.2528500")
remotes::install_zenodo("https://doi.org/10.5281/zenodo.2528500")
remotes::install_zenodo("https://zenodo.org/record/55336")

Motivation

Research software is recommended to be deposited to data repositories for mid-term archival, and to receive a DOI. Now, if an author wants to ping a specific version for a package not on CRAN, they can install a specific release/commit from GitHub with remotes. For research, it could be a useful enhancement to not rely on GitHub, but on a data repository with likely more longterm availability.

[jimhester]

In general remotes is generally feature complete, we are not planning on adding any new remote types at this time.

[dpprdan]

@nuest maybe #509 is helpful?

[jimhester]

As of ffcfd1b the generic functions used internally by remotes are now exported, so for new remote types like this I think implementing them in their own packages makes the most sense.

[shikokuchuo]

@gaborcsardi I wonder if thinking around this remains the same.

After discussions with @wlandau and some of his ideas for the R Repositories Working Group, I am exploring if Zenodo might form one part of a solution. A key advantage is obviously that it is archival quality + integrated with Github, so every cut release automatically updates the latest Zenodo record, whilst all previous versions are retained. As an example, I provide Zenodo DOIs for all of my R packages, and e.g. for something like {targets} at https://zenodo.org/records/10357140. I believe it is also a requirement or at least a recommendation for R-opensci packages.

Please point as to which way to go: PR or separate package. Thanks.

[gaborcsardi]

We are focusing on improving https://github.com/r-lib/pak and we're not going to add any new features to remotes.