I, like Duncan, am just following along here. I think there might be
two distinct questions which it would be useful to keep distinct:
* how to silence the rust-check if desired?
rather than debating whether the rust-check should be always-on,
on-for-CRAN-only, etc., would it provide for useful flexibility to add
an environment variable that enables/disables this functionality? There
are already 168 of these environment variables, how much would one more
cost?
I'm not sure how adding an environment variable to allow easier
user/alternate-repository control of the check is "against the spirit of
the check" ...
All the existing check-regulating env variables ...
cd src/library/tools/R
grep 'Sys.getenv("_R_CHECK' * | sed -e 's/^.*Sys.getenv(//'
| sed -e
's/[,)].*//' | sort | uniq | wc
* should CRAN allow Rust crates to be downloaded?
This is a much more fundamental policy decision, which I have no
opinion about.
cheers
Ben Bolker
On 2025-03-02 12:21 p.m., Duncan Murdoch wrote:> 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 at gmail.com <mailto:murdoch.duncan at
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 at R-project.org>
>> ???? > Date: Sunday, 2 March 2025 at 00.39
>> ???? > To: Mossa Merhi Reimert <mossa at sund.ku.dk
>> <mailto:mossa at sund.ku.dk>>
>> ???? > Cc: r-devel at r-project.org <mailto:r-devel at
r-project.org>
>> ??? <r-devel at r-project.org <mailto: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
>> ??? <mailto:simon.urbanek at 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 at r-project.org <mailto: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
>> ???
<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 at sund.ku.dk
>> ??? <mailto:mossa at sund.ku.dk><mailto:mossa at sund.ku.dk
>> ??? <mailto:mossa at sund.ku.dk>>
>> ???? >>
>> ???? >>
>> ???? >>? ? ? ? [[alternative HTML version deleted]]
>> ???? >>
>> ???? >> ______________________________________________
>> ???? >> R-devel at r-project.org <mailto:R-devel at
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 at r-project.org <mailto:R-devel at
r-project.org> mailing list
>> ???? > https://stat.ethz.ch/mailman/listinfo/r-devel
>> ??? <https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>> ??? ______________________________________________
>> ??? R-devel at r-project.org <mailto:R-devel at r-project.org>
mailing list
>> ??? https://stat.ethz.ch/mailman/listinfo/r-devel
>> ??? <https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
> E-mail is sent at my convenience; I don't expect replies outside of
working hours.