Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Dirk Eddelbuettel
It is also pretty straightforward to roll your own actions and / or use different, simpler YAML setups. I still use a 'rolled forward and maintained by me now version' of the shell script many of us started with at Travis CI. It works, is portable across multiple CI backend, and is still a shell

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Duncan Murdoch
One more change to remotes::install_github("dmurdoch/rcmdcheck@demotions") Now the changes in message severity have to be coded into the DESCRIPTION file of the package being checked. For example, add this line: Config/rcmdcheck/demote/warnings: Compiled code should not call entry point

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Duncan Murdoch
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 ter

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Chris Black
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 _o

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Tim Taylor
> 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. Josiah - I do sympathise but

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Duncan Murdoch
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 and https://developer.r-project.org/blosxom.cgi/R-devel/NEWS/2025/03/22#n2025-0

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Duncan Murdoch
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 se

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Josiah Parry
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 Acti

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Ben Bolker
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 and https://developer.r- pr

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Duncan Murdoch
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_INC

Re: [Rd] R CMD check and CRAN's Rust policy

2025-03-31 Thread Tim Taylor
On Mon, 31 Mar 2025, at 4:50 PM, 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_C