Zenodo and OSF (see e.g.
<https://fairsharing.org/FAIRsharing.g4z879>) are both non-profit
organizations that support archiving -- that is, they both make stronger
guarantees of permanent availability than GitHub does. Possibly Software
Heritage https://www.softwareheritage.org/features/ ?
Zenodo has convenient GitHub integration.
On 2024-05-08 4:01 p.m., Josiah Parry wrote:
Thank you, Ivan, for your really thoughtful feedback! I really appreciate
it!
- I'll see if there are any base R packages that support SHA-2 or SHA-3.
- I'll see if I can get the configure.ac to make the appropriate Rscript
call for configure.win.
- I think the idea of having a single `confgure.ac` file to generate
both configure and configure.win is nice. Guidance with GitHub
actions and
ChatGPT is essentially a must for me since my bash is remedial at best.
Regarding the permanent storage requirement, I find it to be very strange.
I've personally never heard of Zenodo until just now! Does the CRAN team
have recommendations for what is considered "as sufficiently reliable?" I
have repos that have persisted for almost 10 years. I think that is
sufficiently reliable!
The requirement to avoid GitHub feels surprisingly anachronistic given how
central it is to the vast majority of software development. The alternative
I can think of is to create a CDN on cloudflare or something to store the
file independently.
Are there any avenues to have CRAN clarify their positions outside of
one-off processes? It would be quite unfortunate to go through all the work
of creating a way to build, store, and retrieve the dependencies only for
CRAN to decide they don't support it.
On Wed, May 8, 2024 at 3:32 PM Ivan Krylov <ikry...@disroot.org> wrote:
В Wed, 8 May 2024 14:08:36 -0400
Josiah Parry <josiah.pa...@gmail.com> пишет:
With ChatGPT's ability to write autoconf, I *think *I have something
that can work.
You don't have to write autoconf if your configure.ac is mostly a plain
shell script. You can write the configure script itself. Set the PATH
and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the
regular, non-multiarch configure for Unix-like systems) or exec
"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in
configure.win, which you'll also need). You've already wrote the rest
of the code in a language you know well: R.
Autoconf would be useful if you had system-specific dependencies with
the need to perform lots of compile tests. Those would have been a pain
to set up in R. Here you mostly need sys.which() instead of
AC_CHECK_PROGS and command -v.
The configure file runs tools/get-deps.R which will download the
dependencies from the repo if available and verify the checksums.
One of the pain points is the need for a strong, cryptographically
secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake
build, you would be able to use cmake's built in strong hashes (such as
SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only
requires a "checksum". If you figure out a way to use a strong hash
from tools/configure.R for the downloaded tarball, please let us know.
If the checksums don't match, an error is thrown, otherwise it can
continue. I believe this meets the requirements of CRAN?
The other important CRAN requirement is to store the vendor tarball
somewhere as permanent as CRAN itself (see the caveats at the bottom of
https://cran.r-project.org/web/packages/using_rust.html), that is, not
GitHub. I think that Zenodo counts as a sufficiently reliable store.
--
Best regards,
Ivan
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of
working hours.
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
