[Rd] R CMD check and CRAN's Rust policy
Duncan Murdoch
murdoch@dunc@n @end|ng |rom gm@||@com
Sun Mar 2 18:21:39 CET 2025
On 2025-03-02 11:03 a.m., Josiah Parry wrote:
> Well this has surely veered off course!
>
> As the one who filed the BugZilla report, I'd like to redirect the
> conversation and provide further context.
>
> The question should be /"how do we get a dialogue started on this
> bugzilla issue before the next minor /
> /release of R?"/
Isn't this exactly that dialogue?
>
> The current check for Rust-based R package's downloading external
> dependencies works by looking at
> the output logs for the presence of "Downloading crates." This can is
> an entirely fine requirement for
> CRAN—however, due to the fact that it is an error, packages distributed
> through other repositories
> fail the R-CMD check.
I think you misunderstood me. CRAN shares the view I gave that you
should be able to run old code to reproduce old results, but they aren't
the only ones. That's always been a goal of R.
> Folks who use R-universe or PPM or some mysterious third thing may not
> share the same philosophy as
> CRAN and prefer the convenience of fetching the dependencies at compile
> time and not vendoring them.
> An alternative would be for the check to be optionally skipped or become
> a NOTE when the CRAN
> flag is not set and an ERROR otherwise. Skipping this CRAN check is as
> easy as adding `--quiet`
> or setting an environment variable—but that is against the spirit of the
> check.
If it is that easy to skip the check, then I really don't see the issue.
Just ask the repository where you want to put your package to put that
option or environment variable in place, and there's no longer a problem.
Duncan Murdoch
> Ideally, the check can remain, but scoped appropriately.
>
>
> On Sun, Mar 2, 2025 at 6:49 AM Duncan Murdoch <murdoch.duncan using gmail.com
> <mailto:murdoch.duncan using gmail.com>> wrote:
>
> You seem to be taking a confontational tone, which isn't likely to
> encourage a reasonable dialogue.
>
> I've looked for other messages on this, and didn't see any besides this
> one explaining why including check_rust() in the checks is a problem.
> The problem you talk about here is that it encourages vendoring, which
> makes it harder for package authors to count downloads.
>
> To be honest, that doesn't seem like a very serious problem. I assume
> the packages ("crates") we are talking about are open source, so
> this is
> entirely in the spirit of how they are allowed to be distributed.
>
> If they aren't open source, then users of those packages should be
> warned about that, and a check failure is a good way to do that.
>
> So you need to explain why it is important to be able to download and
> install software and not be warned about it.
>
> I am not in R Core or CRAN, but I can suggest why it is better to
> include source in the package: it makes the use of that package more
> reliable in the future. It's not uncommon to run an R computation that
> was written a few years ago. Sometimes libraries or R have changed,
> and
> a user will need to go back to a previous version to reproduce the
> calculation. Being able to able to rebuild a system as it would have
> been back then is important.
>
> Is that possible if the package needs to make a download? The download
> site that worked a few years ago may no longer exist. If the site
> exists, the code versions there may be different.
>
> Those are some of the issues that Simon was alluding to.
>
> Duncan Murdoch
>
>
>
> On 2025-03-02 5:45 a.m., Mossa Merhi Reimert via R-devel wrote:
> > Dear Simon Urbanek,
> >
> > There has been very little engagement with the issue I referred
> to. If it was decided that this “check” ought to be part of the
> default checks for R,
> > then that could have been written to us. Either on the
> bugs.r-project.org <http://bugs.r-project.org> or the proposed
> patch. Before we talk about anything else,
> > it does seem very strange that we cannot get a reasonable
> dialogue going.
> >
> > I would like to say that the R/Rust community has grown
> substantially. From my end, there are 3 bindings project, extendr,
> savvy, and roxido.
> > Then, there are now many rust-based packages on CRAN, see this
> most recent compiled list https://github.com/nanxstats/r-rust-pkgs
> <https://github.com/nanxstats/r-rust-pkgs>.
> > There is also proof-of-concept
> https://github.com/r-rust/hellorust
> <https://github.com/r-rust/hellorust> that integrates `cargo`,
> rust’s official build system, with R’s package build system,
> > and https://github.com/extendr/hellorustc
> <https://github.com/extendr/hellorustc>, which showcases how Rust
> compiler could be directly linked with R’s package system.
> >
> > Let me say, that the current R CMD check is not meant to be
> “helpful”. When a package is built, `cargo` tells the user
> “Downloading crates”.
> > Thus, this information is already conveyed to the user.
> >
> > Personally, I do wish we could debate this requirement further. I
> do not believe that having R-packages on CRAN vendor rust dependencies
> > as a good policy. Download statistics is a success metric of a
> given r-package and rust packages. By insisting on vendoring, and thus
> > side-stepping `cargo` / crates.io <http://crates.io>, we are
> robbing upstream authors of their download-numbers. I do not think
> such policy is honourable.
> >
> > While C/C++ do not have official package repositories, it could
> be thought of, as fair game, to have CRAN act as a pseudo package
> manager for C/C++ libraries.
> > I’m not going to argue for or against this part.
> >
> > There are many objections from the CRAN side to all things
> related to Rust. I don’t want to open multiple topics in the same
> thread.
> > But there is plenty to bring up. And I had hoped we could talk
> this little issue through, before embarking on a larger discussion.
> > I do not appreciate the “random demands” comment, as this is not
> a demand, nor is it random.
> > I have inquired my end of the community for suggestions
> > to compile a larger proposal, but then I was afraid that this
> would be perceived as a big, bulky demand.
> >
> > Rust is not C/C++/Java, and the support for Rust cannot look like
> the support for these languages.
> >
> >
> >
> > From: Simon Urbanek <simon.urbanek using R-project.org>
> > Date: Sunday, 2 March 2025 at 00.39
> > To: Mossa Merhi Reimert <mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>>
> > Cc: r-devel using r-project.org <mailto:r-devel using r-project.org>
> <r-devel using r-project.org <mailto:r-devel using r-project.org>>
> > Subject: Re: [Rd] R CMD check and CRAN's Rust policy
> > [Du får ikke ofte mails fra simon.urbanek using r-project.org
> <mailto:simon.urbanek using r-project.org>. Få mere at vide om, hvorfor
> dette er vigtigt, på https://aka.ms/LearnAboutSenderIdentification
> <https://aka.ms/LearnAboutSenderIdentification> ]
> >
> > Mossa,
> >
> > the issue you cite is lacking any pertinent information and it's
> not even clear why it should be an issue. The check is perfectly
> justified, it just reports whether a package using rust declares
> this correctly and where it downloads 3rd party content - something
> that is important to R users in general and not related to CRAN. I
> don't see how any of this is "prohibitive" it just calls out what
> the package is already doing.
> >
> > As discussed before, my hope was that the "R"ust community will
> mature enough to work on proper support. It is not clear that it
> happened yet, but once it does it would make sense to talk about
> support just as we have for C, C++ and Java, so certainly that
> should be the right discussion. However, it will have to start with
> some thinking and a proposal on how the associated issues (compiler
> support, versioning, dependency sources etc.) are to be addressed,
> as opposed to making random demands. All this has nothing to do with
> CRAN so the issue you mention seems irrelevant to the progress. Also
> I'd like to know what are the "challenges embedded in R itself".
> >
> > Cheers,
> > Simon
> >
> >
> >> On Mar 2, 2025, at 8:45 AM, Mossa Merhi Reimert via R-devel
> <r-devel using r-project.org <mailto:r-devel using r-project.org>> wrote:
> >>
> >> Hello everyone!
> >>
> >> I'm Mossa, I'm one of the maintainers of extendr, an automated
> generation of bindings project for
> >> Rust code, for use in R-packages.
> >>
> >> I'm writing to you, as R 4.4.3 was just released, and there have
> not been
> >> follow-up on an issue important to us. Link to the issue as
> discussed on r-devel
> >> https://stat.ethz.ch/pipermail/r-devel/2024-October/083666.html
> <https://stat.ethz.ch/pipermail/r-devel/2024-October/083666.html>
> >>
> >> A community member has provided a suggestion to a patch here
> https://github.com/r-devel/r-svn/pull/182
> <https://github.com/r-devel/r-svn/pull/182>, and we have also
> attempted to bring it up on
> >> Bugzilla: https://bugs.r-project.org/show_bug.cgi?id=18806
> <https://bugs.r-project.org/show_bug.cgi?id=18806>
> >>
> >> TLDR: Default `R CMD check` uses additional CRAN-specific checks
> for Rust,
> >> instead of keeping this behind the --as-cran flag.
> >>
> >> I would like to say, that there is a growing interest in Rust
> within the R community.
> >> And generally, Rust becoming a widely adopted language within
> the Python community (including the scientific part of that
> community). It is time to deal with the
> >> pain points with using Rust in R.
> >>
> >> Therefore, I would kindly ask that we have a dialogue on how to
> remedy the issue above first, and how we may deal with other issues
> going forward. There are both challenges embedded in R itself, and
> the current CRAN policy for Rust is prohibitive.
> >>
> >>
> >>
> >> Mossa Merhi Reimert
> >> Postdoctoral Researcher
> >>
> >> K�benhavns Universitet
> >> Department of Veterinary and Animal Sciences
> >> Animal Welfare and Disease Control
> >> Gr�nneg�rdsvej 8
> >> 1870 Frederiksberg C
> >> Denmark
> >>
> >> +45 35324135
> >> mossa using sund.ku.dk
> <mailto:mossa using sund.ku.dk><mailto:mossa using sund.ku.dk
> <mailto:mossa using sund.ku.dk>>
> >>
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-devel using r-project.org <mailto:R-devel using r-project.org> mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> <https://stat.ethz.ch/mailman/listinfo/r-devel>
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel using r-project.org <mailto:R-devel using r-project.org> mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
> ______________________________________________
> R-devel using r-project.org <mailto:R-devel using r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
More information about the R-devel
mailing list