Ideally, the check can remain, but scoped appropriately.
On Sun, Mar 2, 2025 at 6:49 AM Duncan Murdoch
<murdoch.dun...@gmail.com <mailto:murdoch.dun...@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.urba...@r-project.org>
> Date: Sunday, 2 March 2025 at 00.39
> To: Mossa Merhi Reimert <mo...@sund.ku.dk
<mailto:mo...@sund.ku.dk>>
> Cc: r-devel@r-project.org <mailto:r-devel@r-project.org>
<r-devel@r-project.org <mailto:r-devel@r-project.org>>
> Subject: Re: [Rd] R CMD check and CRAN's Rust policy
> [Du får ikke ofte mails fra simon.urba...@r-project.org
<mailto:simon.urba...@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@r-project.org <mailto:r-devel@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
>> mo...@sund.ku.dk
<mailto:mo...@sund.ku.dk><mailto:mo...@sund.ku.dk
<mailto:mo...@sund.ku.dk>>
>>
>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-devel@r-project.org <mailto:R-devel@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@r-project.org <mailto:R-devel@r-project.org> mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
______________________________________________
R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
<https://stat.ethz.ch/mailman/listinfo/r-devel>
