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?
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>
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>> 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.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>>
> >>> > Cc: r-devel@r-project.org <mailto:r-devel@r-project.org>
> >>> <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>. 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@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>
> >>> >>
> >>> >> 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
> >>> >> 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> mailing
> list
> >>> >> 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> 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>
> >>>
> >>
> >> ______________________________________________
> >> 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
