[Rd] R CMD check and CRAN's Rust policy
Duncan Murdoch
murdoch@dunc@n @end|ng |rom gm@||@com
Tue Apr 1 01:20:00 CEST 2025
On 2025-03-31 4:50 p.m., Duncan Murdoch wrote:
> Just for fun I forked rcmdcheck and added arguments to it to allow
> particular messages to be changed in severity.
>
> For example, if the WARNING message says something which matches the
> regexp "Compiled code should not call entry points which might terminate
> R" you could run
>
> rcmdcheck::rcmdcheck(".", demote = list(warnings = "Compiled code
> should not call entry points which might terminate R"))
>
> and the warning will be counted as a NOTE. The decision about whether
> to signal an error from the run will be based on the value after demotion.
>
> I haven't done anything with the Github action, but users can play
> with this fork if they like. It can be installed using
>
> remotes::install_github("dmurdoch/rcmdcheck")
Sorry, that should be
remotes::install_github("dmurdoch/rcmdcheck using demotions")
Duncan Murdoch
>
> You can install custom builds in a Github action fairly easily, but it's
> hard to add a new argument to a call deep within the action script. A
> simpler approach would be to fork my fork and set the default value for
> "demote" to whatever you want, then install your own fork during the
> Github action.
>
> Comments are welcome.
>
> 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:
>>>> Duncan, the changes to symbols checking was introduced March 22nd see
>>>> https://bugs.r-project.org/show_bug.cgi?id=18789 <https://bugs.r-
>>>> project.org/show_bug.cgi?id=18789> and https://developer.r-
>>>> project.org/blosxom.cgi/R-devel/NEWS/2025/03/22#n2025-03-22 <https://
>>>> developer.r-project.org/blosxom.cgi/R-devel/
>>>> NEWS/2025/03/22#n2025-03-22>. But that is unrelated.
>>>
>>> Sorry, I missed that.
>>>
>>>>
>>>> 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 using gmail.com <mailto:murdoch.duncan using 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.duncan using gmail.com <mailto:murdoch.duncan using gmail.com>
>>>> > <mailto:murdoch.duncan using gmail.com
>>>> <mailto:murdoch.duncan using 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 using gmail.com
>>>> <mailto:murdoch.duncan using gmail.com> <mailto:murdoch.duncan using gmail.com
>>>> <mailto:murdoch.duncan using gmail.com>>
>>>> > <mailto:murdoch.duncan using gmail.com
>>>> <mailto:murdoch.duncan using gmail.com> <mailto:murdoch.duncan using gmail.com
>>>> <mailto:murdoch.duncan using 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.urbanek using R-project.org>
>>>> > >>> > Date: Sunday, 2 March 2025 at 00.39
>>>> > >>> > To: Mossa Merhi Reimert <mossa using sund.ku.dk
>>>> <mailto:mossa using sund.ku.dk>
>>>> > <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>>
>>>> > >>> <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>
>>>> <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>>>>
>>>> > >>> > Cc: r-devel using r-project.org
>>>> <mailto:r-devel using r-project.org>
>>>> > <mailto:r-devel using r-project.org <mailto:r-devel using r-project.org>>
>>>> <mailto:r-devel using r-project.org <mailto:r-devel using r-project.org>
>>>> > <mailto:r-devel using r-project.org <mailto:r-devel using r-project.org>>>
>>>> > >>> <r-devel using r-project.org
>>>> <mailto:r-devel using r-project.org> <mailto:r-devel using r-project.org
>>>> <mailto:r-devel using r-project.org>>
>>>> > <mailto:r-devel using r-project.org <mailto:r-devel using r-project.org>
>>>> <mailto:r-devel using r-project.org <mailto:r-devel using r-project.org>>>>
>>>> > >>> > Subject: Re: [Rd] R CMD check and CRAN's Rust
>>>> policy
>>>> > >>> > [Du får ikke ofte mails fra
>>>> simon.urbanek using r-project.org <mailto:simon.urbanek using r-project.org>
>>>> > <mailto:simon.urbanek using r-project.org
>>>> <mailto:simon.urbanek using r-project.org>>
>>>> > >>> <mailto:simon.urbanek using r-project.org
>>>> <mailto:simon.urbanek using r-project.org>
>>>> > <mailto:simon.urbanek using r-project.org
>>>> <mailto:simon.urbanek using 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 using r-project.org
>>>> <mailto:r-devel using r-project.org> <mailto:r-devel using r-project.org
>>>> <mailto:r-devel using r-project.org>>
>>>> > <mailto:r-devel using r-project.org <mailto:r-devel using r-project.org>
>>>> <mailto:r-devel using r-project.org <mailto:r-devel using 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
>>>> > >>> >> mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>
>>>> <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>>
>>>> > >>> <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>
>>>> > <mailto:mossa using sund.ku.dk
>>>> <mailto:mossa using sund.ku.dk>>><mailto:mossa using sund.ku.dk
>>>> <mailto:mossa using sund.ku.dk>
>>>> > <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>>
>>>> > >>> <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>
>>>> <mailto:mossa using sund.ku.dk <mailto:mossa using sund.ku.dk>>>>
>>>> > >>> >>
>>>> > >>> >>
>>>> > >>> >> [[alternative HTML version deleted]]
>>>> > >>> >>
>>>> > >>> >> ______________________________________________
>>>> > >>> >> R-devel using r-project.org
>>>> <mailto:R-devel using r-project.org> <mailto:R-devel using r-project.org
>>>> <mailto:R-devel using r-project.org>>
>>>> > <mailto:R-devel using r-project.org <mailto:R-devel using r-project.org>
>>>> <mailto:R-devel using r-project.org <mailto:R-devel using 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 using r-project.org
>>>> <mailto:R-devel using r-project.org> <mailto:R-devel using r-project.org
>>>> <mailto:R-devel using r-project.org>>
>>>> > <mailto:R-devel using r-project.org <mailto:R-devel using r-project.org>
>>>> <mailto:R-devel using r-project.org <mailto:R-devel using 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 using r-project.org <mailto:R-devel using r-project.org>
>>>> <mailto:R-devel using r-project.org <mailto:R-devel using r-project.org>>
>>>> > <mailto:R-devel using r-project.org <mailto:R-devel using r-project.org>
>>>> <mailto:R-devel using r-project.org <mailto:R-devel using 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 using r-project.org <mailto:R-devel using r-project.org>
>>>> <mailto:R-devel using r-project.org <mailto:R-devel using 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 using r-project.org <mailto:R-devel using r-project.org>
>>>> <mailto:R-devel using r-project.org <mailto:R-devel using 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>>
>>>> >
>>>>
>>>
>>
>
More information about the R-devel
mailing list