I took a more extreme version of this approach for a project that keeps many R packages in a monorepo and checks them all at once, where we do a lot of saying “let’s ignore this warning _in this package_ until someone has a chance to fix it properly, but still fail the build if it shows up in _other packages_”.
The key idea in our approach is for each package you check to cache a previous check result that contains the warning(s) you want to ignore, then compare the current check against it and have your action fail only on _newly added_ warnings. My implementation[1] is brittle and fussy and could be simplified a lot if you’re only checking one package at a time, but may be a useful starting point. [1] https://github.com/PecanProject/pecan/blob/develop/scripts/check_with_errors.R > On Mar 31, 2025, at 11:33 AM, Duncan Murdoch <murdoch.dun...@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: >>>> 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.dun...@gmail.com <mailto:murdoch.dun...@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.dun...@gmail.com <mailto:murdoch.dun...@gmail.com> >>>> > <mailto:murdoch.dun...@gmail.com >>>> <mailto: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> <mailto:murdoch.dun...@gmail.com >>>> <mailto:murdoch.dun...@gmail.com>> >>>> > <mailto:murdoch.dun...@gmail.com >>>> <mailto:murdoch.dun...@gmail.com> <mailto: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> >>>> <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.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> >>>> > <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk>> >>>> > >>> <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk> >>>> <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk>>>> >>>> > >>> > Cc: r-devel@r-project.org >>>> <mailto:r-devel@r-project.org> >>>> > <mailto:r-devel@r-project.org <mailto:r-devel@r-project.org>> >>>> <mailto:r-devel@r-project.org <mailto:r-devel@r-project.org> >>>> > <mailto:r-devel@r-project.org <mailto:r-devel@r-project.org>>> >>>> > >>> <r-devel@r-project.org >>>> <mailto:r-devel@r-project.org> <mailto:r-devel@r-project.org >>>> <mailto:r-devel@r-project.org>> >>>> > <mailto:r-devel@r-project.org <mailto:r-devel@r-project.org> >>>> <mailto: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> >>>> > <mailto:simon.urba...@r-project.org >>>> <mailto:simon.urba...@r-project.org>> >>>> > >>> <mailto:simon.urba...@r-project.org >>>> <mailto:simon.urba...@r-project.org> >>>> > <mailto: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> >>>> > <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@r-project.org >>>> <mailto:r-devel@r-project.org> <mailto:r-devel@r-project.org >>>> <mailto:r-devel@r-project.org>> >>>> > <mailto:r-devel@r-project.org <mailto:r-devel@r-project.org> >>>> <mailto: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> >>>> > <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 >>>> > >>> >> mo...@sund.ku.dk <mailto:mo...@sund.ku.dk> >>>> <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk>> >>>> > >>> <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk> >>>> > <mailto:mo...@sund.ku.dk >>>> <mailto:mo...@sund.ku.dk>>><mailto:mo...@sund.ku.dk >>>> <mailto:mo...@sund.ku.dk> >>>> > <mailto:mo...@sund.ku.dk <mailto:mo...@sund.ku.dk>> >>>> > >>> <mailto: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> <mailto:R-devel@r-project.org >>>> <mailto:R-devel@r-project.org>> >>>> > <mailto:R-devel@r-project.org <mailto:R-devel@r-project.org> >>>> <mailto: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> >>>> > <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@r-project.org >>>> <mailto:R-devel@r-project.org> <mailto:R-devel@r-project.org >>>> <mailto:R-devel@r-project.org>> >>>> > <mailto:R-devel@r-project.org <mailto:R-devel@r-project.org> >>>> <mailto: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> >>>> > <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@r-project.org <mailto:R-devel@r-project.org> >>>> <mailto:R-devel@r-project.org <mailto:R-devel@r-project.org>> >>>> > <mailto:R-devel@r-project.org <mailto:R-devel@r-project.org> >>>> <mailto: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> >>>> > <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@r-project.org <mailto:R-devel@r-project.org> >>>> <mailto: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> >>>> > <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> >>>> <mailto: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> >>>> > <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
