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 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.
There is also proof-of-concept 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, 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, 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 at R-project.org>
Date: Sunday, 2 March 2025 at 00.39
To: Mossa Merhi Reimert <mossa at sund.ku.dk>
Cc: r-devel at r-project.org <r-devel at r-project.org>
Subject: Re: [Rd] R CMD check and CRAN's Rust policy
[Du f?r ikke ofte mails fra simon.urbanek at r-project.org. F? mere at vide om,
hvorfor dette er vigtigt, p? 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 at
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
>
> A community member has provided a suggestion to a patch here
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
>
> 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 at sund.ku.dk<mailto:mossa at sund.ku.dk>
>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]