Or, alternatively, if this could be a NOTE when the `--as-cran` flag
isn't set but a WARNING when it is?
Re-vendoring dependencies each time they are changed during the
development lifecycle is quite a bit. However, vendoring once prior to
publishing makes good sense.
Is there a balance we can strike here to lower development friction but
also ensure the robust package installation requirements when expected?
Using
On Sun, Mar 2, 2025 at 11:42 AM Duncan Murdoch <murdoch.dun...@gmail.com
<mailto:murdoch.dun...@gmail.com>> wrote:
On 2025-03-02 1:09 p.m., Ben Bolker wrote:
> 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 may have misunderstood Josiah. I thought his message said that it is
already easy to silence the check, by stopping the code from issuing
the
message the check is looking for.
Presumably the package shouldn't do that, but if there's an environment
variable that can be set to do it, then the repository or user can
choose to do it, so there's no need for R to add another environment
variable.
BTW, as far as I can see current R-devel doesn't issue an error, it
just
issues warnings about two issues:
- the package is downloading crates
- the rustc compiler doesn't report a version number
Duncan Murdoch
>
> 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.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>
<mailto: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>
<http://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>
>>> <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>
>>> <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>
>>> <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>
<http://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>
>>> <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk>>>
>>> > Cc: r-devel@r-project.org
<mailto:r-devel@r-project.org> <mailto:r-devel@r-project.org
<mailto:r-devel@r-project.org>>
>>> <r-devel@r-project.org <mailto:r-devel@r-project.org>
<mailto: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>
>>> <mailto: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>
>>> <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>
<mailto: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>
>>>
<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>
>>> <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>
>>> <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>><mailto: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>
<mailto: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>
>>> <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>
<mailto: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>
>>> <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>
<mailto: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>
>>> <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>
>
______________________________________________
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>
