Message-ID: <703123c9-c09e-4e14-8f4e-75ffd3c5931f@gmail.com>
Date: 2025-03-31T16:23:54Z
From: Duncan Murdoch
Subject: R CMD check and CRAN's Rust policy
In-Reply-To: <CAL3ufUJVe_jgfHH==EcfxuGiSbQ13KRXTSEP8-oYKafCPNR-+A@mail.gmail.com>
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.duncan at gmail.com
> <mailto:murdoch.duncan at 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.duncan at gmail.com <mailto:murdoch.duncan at gmail.com>
> <mailto: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>
> <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.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>
> >>> <mailto: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> <mailto: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>
> <mailto: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>
> >>>? ??? <mailto: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>
> >>>? ??? <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>
> <mailto: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>
> >>>
> <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
> >>>? ???? >> mossa at sund.ku.dk <mailto:mossa at sund.ku.dk>
> >>>? ??? <mailto:mossa at sund.ku.dk
> <mailto:mossa at sund.ku.dk>><mailto: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>
> <mailto: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>
> >>>? ??? <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>
> <mailto: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>
> >>>? ??? <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>
> <mailto: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>
> >>>? ??? <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 <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>
>