On Mon, Mar 31, 2025 at 9:23 AM Duncan Murdoch
<murdoch.dun...@gmail.com <mailto:murdoch.dun...@gmail.com>> wrote:
On 2025-03-31 11:50 a.m., Josiah Parry wrote:
> Following up with this as I address the new R-devel "Compiled code
> should not call entry points which might terminate R" WARNING and
this
> issue has reared its head again.
>
> Would a path forward be an environment variable similar
> to _R_CHECK_CRAN_INCOMING_ to skip this check primarily for GitHub
> Actions and CI?
The "Compiled code should not call entry points which might
terminate R"
isn't a new warning. I think the last change to it was made in 2022.
Maybe your code, or code in one of the libraries you use, has
changed?
Duncan Murdoch
>
> 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>
> <mailto: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>>
> <mailto: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>>
> <http://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>>
> >>> <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>>
> >>> <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>>
> >>> <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>>
> <http://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>>
> >>> <mailto: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>>
<mailto: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>>
> <mailto: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>>
> >>> <mailto: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>>
> >>> <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>>
> <mailto: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>>
> >>>
> <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>>
> >>> <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>>
> >>> <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>>><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 <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>>
> <mailto: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>>
> >>> <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>>
> <mailto: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>>
> >>> <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>>
> <mailto: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>>
> >>> <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>
<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>>
>
