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]]
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
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]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
Mossa,> On Mar 2, 2025, at 11:45 PM, Mossa Merhi Reimert <mossa at sund.ku.dk> wrote: > > 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 don't see anything from you on this list - your first engagement was yesterday. I have no idea what you refer to as "us" and what makes you think you should have been notified if no one heard from you before. A start of any engagement is to start communication, so here we are, perhaps not the most fortunate way to start off, but we have a discussion and there is hope.> 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. >I think this part of the problem - there is no systematic rust support, so each package author does something differently. As much as it is nice to have the freedom to have many different implementation of the same thing, I would argue that in cases like language support it makes more sense to combine the effort into one solution (after everyone experimented and gained enough experience) that is easy to manage and is well maintained. This is what happened to most mature languages such as C++, Java and Python. That would avoid the "hacks" in place today (I'm referring to the check).> 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. >You are jumping issues here: as I said before this has nothing to do with CRAN. So let us first take CRAN out of the picture and talk about the check. The check does two things: a) it checks that the package correctly declares rust dependency and b) checks whether the package uses 3rd party dynamic downloads. Since the "R"ust community has yet to come up with any systematic rust support, both seem very reasonable checks. We want to know if a package requires rust by checking the DESCRIPTION file alone so the user can make an informed decision whether they want (or even can) use the package. It is also important to know if a package can accesses 3rd party resources online. Due to rising security threats it is increasingly common to not allow analytics machines to have access to the Internet so sensitive data cannot be leaked. It also opens the can of legality as the resulting software may not adhere to the license of the package and there is no guarantee that the user will still have the license. Moreover, reproducibility is very important to R users so it should be possible to reproduce the installation - which excludes 3rd party distributed systems which don't have any such guarantees unless they provide a way to fully vendor dependencies. So, in short, there are many reasons why the user should know about the things checked so they can make informed decisions. Whether this is the best way to signal that is up for debate. Your argument is that the important reason is a popularity contest based on download statistics. I would argue that it is a very weak reason, since vast majority of R users does not use source installations to install packages, so there is no "robbing" of upstream authors - the statistics don't reflect real usage anyway. If you want to propose improvements to the check, I'm sure it would be appreciated, but putting it behind --as-cran doesn't seem the right approach nor does that solve the problem in any way as the issues are not CRAN-specifc. I would think that some proposal to declare rust requirements (incl. toolchain) and have declared a way to vendor dependencies to address off-line install, licensing and security issues uniformly for rust packages would be steps in the right direction.> 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. >Why not? They all require compilers, ways to deal with dependencies and produce binaries - so does Rust. It's just one of many similar languages. The key is to have proper support instead of having each package deal with the complexities alone. Cheers, Simon