[Rd] R CMD check and CRAN's Rust policy
Duncan Murdoch
murdoch@dunc@n @end|ng |rom gm@||@com
Mon Mar 31 20:33:15 CEST 2025
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:
>>> 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