> 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.
I agree with you. It seems no one explained what problem it causes to them.
In my understanding (disclaimer: I haven't hit this by myself yet), the
problem is that the "Downloading crates ..." log raises a warning, which
makes the CI check fail. Although it's true that none of this is
"prohibitive," it's just inconvenient.
Maybe it's possible to make it a NOTE instead of a WARNING at least?
I'm suggesting so because otherwise this will end up encouraging the
package authors to hide these logs as a workaround to avoid the CI failure.
As it's very easy, I'm personally fine with the status quo, but if it
becomes a common practice, it makes it harder for the CRAN maintainers to
investigate the installation logs.
Best,
Yutani
2025年3月2日(日) 23:49 Duncan Murdoch <murdoch.dun...@gmail.com>:
> 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.urba...@r-project.org>
> > Date: Sunday, 2 March 2025 at 00.39
> > To: Mossa Merhi Reimert <mo...@sund.ku.dk>
> > Cc: r-devel@r-project.org <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. 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@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
> >> mo...@sund.ku.dk<mailto:mo...@sund.ku.dk>
> >>
> >>
> >> [[alternative HTML version deleted]]
> >>
> >> ______________________________________________
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> > [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
