On Mar 31, 2025, at 11:33?AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
I don't see an easy way, but I think this is an approach:
Configure r-lib/actions/check-r-package to not fail on warnings, only on errors, and to upload the result of the rcmdcheck() run. I think it will contain all errors, warnings, and notes. There are options "error-on" which should be set to "error", and "upload-result", which should be set to "true". So this is the easy part.
Then examine those results, ignore the warnings you don't care about, and trigger on warnings you do care about. I have never written a github action, but this one sounds possible.
Duncan Murdoch
On 2025-03-31 1:48 p.m., Ben Bolker wrote:
On 2025-03-31 1:04 p.m., Duncan Murdoch wrote:
On 2025-03-31 12:41 p.m., Josiah Parry wrote:
To Tim's comment?the check is a simple grep of the installation log
for "Downloading crates." This could be easily circumvented on CRAN
and locally by suppressing stdout/err. But that would be adversarial
and I would like to adhere to the intent of the check.
I think Tim was suggesting that you modify your Github action to ignore
this particular warning. The warning would still appear, but it
wouldn't cause a check failure.
Duncan Murdoch
At a very quick look, I don't see an easy way to do that (but I am
admittedly really bad at doing stuff with Github actions). Maybe longer
term, but it feels like the best way to do this would be to request a
feature in `rcmdcheck` that allowed the user to request ignoring
specific warnings (e.g. specified by regexp?), then expose that feature
in the r-check-package action (or whatever it's called ...)
On Mon, Mar 31, 2025 at 9:23?AM Duncan Murdoch
<murdoch.duncan at gmail.com <mailto:murdoch.duncan at 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
> 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`
> 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
> publishing makes good sense.
>
> Is there a balance we can strike here to lower development
> also ensure the robust package installation requirements when
>
> Using
>
>
>
>
> On Sun, Mar 2, 2025 at 11:42?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:
>
> On 2025-03-02 1:09 p.m., Ben Bolker wrote:
> > I, like Duncan, am just following along here. I think
> > two distinct questions which it would be useful to keep
> >
> > * how to silence the rust-check if desired?
> >
> > rather than debating whether the rust-check should be
> > on-for-CRAN-only, etc., would it provide for useful
> > an environment variable that enables/disables this
> > are already 168 of these environment variables, how much
>
> I may have misunderstood Josiah. I thought his message said
> already easy to silence the check, by stopping the code from
> the
> message the check is looking for.
>
> Presumably the package shouldn't do that, but if there's an
> variable that can be set to do it, then the repository or
> choose to do it, so there's no need for R to add another
> variable.
>
> BTW, as far as I can see current R-devel doesn't issue an
> 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
> > user/alternate-repository control of the check is
> > 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
> > 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
> >>> conversation and provide further context.
> >>>
> >>> The question should be /"how do we get a dialogue
> >>> 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
> >>> dependencies works by looking at
> >>> the output logs for the presence of "Downloading
> >>> an entirely fine requirement for
> >>> CRAN?however, due to the fact that it is an error,
> >>> distributed through other repositories
> >>> fail the R-CMD check.
> >>
> >> I think you misunderstood me. CRAN shares the view I
> >> should be able to run old code to reproduce old
> >> the only ones. That's always been a goal of R.
> >>
> >>> Folks who use R-universe or PPM or some mysterious third
> >>> share the same philosophy as
> >>> CRAN and prefer the convenience of fetching the
> >>> compile time and not vendoring them.
> >>> An alternative would be for the check to be optionally
> >>> become a NOTE when the CRAN
> >>> flag is not set and an ERROR otherwise. Skipping this
> >>> easy as adding `--quiet`
> >>> or setting an environment variable?but that is against
> >>
> >> If it is that easy to skip the check, then I really
> >> Just ask the repository where you want to put your
> >> option or environment variable in place, and there's no
> >>
> >> 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>>
> <mailto:murdoch.duncan at gmail.com
<mailto:murdoch.duncan at gmail.com> <mailto:murdoch.duncan at gmail.com
<mailto:murdoch.duncan at gmail.com>>>>
> >>>
> >>> You seem to be taking a confontational tone, which
> >>> encourage a reasonable dialogue.
> >>>
> >>> I've looked for other messages on this, and didn't
> >>> this
> >>> one explaining why including check_rust() in the
> >>> The problem you talk about here is that it
> >>> which
> >>> makes it harder for package authors to count
> >>>
> >>> To be honest, that doesn't seem like a very serious
> >>> assume
> >>> the packages ("crates") we are talking about are
> >>> this is
> >>> entirely in the spirit of how they are allowed to be
> >>>
> >>> If they aren't open source, then users of those
> >>> warned about that, and a check failure is a good
> >>>
> >>> So you need to explain why it is important to be
> >>> install software and not be warned about it.
> >>>
> >>> I am not in R Core or CRAN, but I can suggest why
> >>> include source in the package: it makes the use of
> >>> reliable in the future. It's not uncommon to run
> >>> that
> >>> was written a few years ago. Sometimes libraries
> >>> and
> >>> a user will need to go back to a previous version to
> >>> calculation. Being able to able to rebuild a
> >>> been back then is important.
> >>>
> >>> Is that possible if the package needs to make a
> >>> download
> >>> site that worked a few years ago may no longer
> >>> exists, the code versions there may be different.
> >>>
> >>> Those are some of the issues that Simon was
> >>>
> >>> Duncan Murdoch
> >>>
> >>>
> >>>
> >>> On 2025-03-02 5:45 a.m., Mossa Merhi Reimert via
> >>> > Dear Simon Urbanek,
> >>> >
> >>> > There has been very little engagement with the
> >>> to. If it was decided that this ?check? ought to be
> >>> default checks for R,
> >>> > then that could have been written to us. Either
> >>> patch. Before we talk about anything else,
> >>> > it does seem very strange that we cannot get a
> >>> >
> >>> > I would like to say that the R/Rust community
> >>> substantially. From my end, there are 3 bindings
> >>> > Then, there are now many rust-based packages on
> >>> most recent compiled list
> >>> > There is also proof-of-concept
> >>> rust?s official build system, with R?s package
> >>> compiler could be directly linked with R?s package
> >>> >
> >>> > Let me say, that the current R CMD check is
> >>> ?helpful?. When a package is built, `cargo` tells
> >>> ?Downloading crates?.
> >>> > Thus, this information is already conveyed to
> >>> >
> >>> > Personally, I do wish we could debate this
> >>> do not believe that having R-packages on CRAN
> >>> > as a good policy. Download statistics is a
> >>> given r-package and rust packages. By insisting on
> >>> > side-stepping `cargo` / crates.io
> >>> robbing upstream authors of their download-numbers.
> >>> such policy is honourable.
> >>> >
> >>> > While C/C++ do not have official package
> >>> be thought of, as fair game, to have CRAN act as a
> >>> 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
> >>> related to Rust. I don?t want to open multiple
> >>> > But there is plenty to bring up. And I had
> >>> this little issue through, before embarking on a
> >>> > I do not appreciate the ?random demands?
> >>> a demand, nor is it random.
> >>> > I have inquired my end of the community for
> >>> > to compile a larger proposal, but then I was
> >>> would be perceived as a big, bulky demand.
> >>> >
> >>> > Rust is not C/C++/Java, and the support for Rust
> >>> 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>>
> >>> <mailto: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>>
<mailto: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>>
> <mailto: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
> >>> > [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>>
> >>> <mailto: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?
> >>> >
> >>> > Mossa,
> >>> >
> >>> > the issue you cite is lacking any pertinent
> >>> not even clear why it should be an issue. The
> >>> justified, it just reports whether a package
> >>> this correctly and where it downloads 3rd party
> >>> that is important to R users in general and not
> >>> don't see how any of this is "prohibitive" it just
> >>> the package is already doing.
> >>> >
> >>> > As discussed before, my hope was that the "R"ust
> >>> mature enough to work on proper support. It is not
> >>> happened yet, but once it does it would make sense
> >>> support just as we have for C, C++ and Java, so
> >>> should be the right discussion. However, it will
> >>> some thinking and a proposal on how the associated
> >>> support, versioning, dependency sources etc.) are
> >>> as opposed to making random demands. All this has
> >>> CRAN so the issue you mention seems irrelevant to
> >>> I'd like to know what are the "challenges
> >>> >
> >>> > Cheers,
> >>> > Simon
> >>> >
> >>> >
> >>> >> On Mar 2, 2025, at 8:45 AM, Mossa Merhi
> >>> <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>>
> <mailto: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
> >>> generation of bindings project for
> >>> >> Rust code, for use in R-packages.
> >>> >>
> >>> >> I'm writing to you, as R 4.4.3 was just
> >>> >> follow-up on an issue important to us. Link
> >>> discussed on r-devel
> >>> >>
> >>> >> A community member has provided a suggestion
> >>> attempted to bring it up on
> >>> >>
> >>> >> TLDR: Default `R CMD check` uses additional
> >>> >> instead of keeping this behind the --as-cran
> >>> >>
> >>> >> I would like to say, that there is a growing
> >>> within the R community.
> >>> >> And generally, Rust becoming a widely adopted
> >>> the Python community (including the scientific part
> >>> community). It is time to deal with the
> >>> >> pain points with using Rust in R.
> >>> >>
> >>> >> Therefore, I would kindly ask that we have a
> >>> remedy the issue above first, and how we may deal
> >>> going forward. There are both challenges embedded
> >>> 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>>><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 <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>>
> <mailto: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>>>
> >>> >
> >>> > [[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>>
> <mailto: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>>
> <mailto: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>>
mailing list
>
> ______________________________________________
> 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