On Tue, 25 Jun 2024, Josiah Parry wrote:
> Hey folks,
>
> I'm sure many of you all woke to the same message I did: "Please
correct
> before 2024-07-09 to safely retain your package on CRAN" caused by
Non-API
> changes to CRAN.
>
> This is quite unexpected as Luke Tierney's June 6th email writes
(emphasis
> mine):
>
> "An *experimental* *effort* is underway to add annotations to the
WRE..."
>
> "*Once things have gelled a bit more *I hope to turn this into a blog
> post that will include some examples of moving non-API entry point
> uses into compliance."
>
> Since then there has not been any indication of stabilization of the
> Non-API changes nor has there been a blog post outlining how to migrate. As
> things have been coming and going from the Non-API changes for quite some
> time now, we (the royal we, here) have been waiting for an official
> announcement from CRAN on the stabilizing changes.
I posted an update to this list a few days ago. If you missed it you
can find it in the archive.
> *Can we extend this very short notice to handle the Non-API changes before
> removal from CRAN? *
Timing decisions are up to CRAN.
> In the case of the 3 packages I have to fix within 2 weeks, these are all
> using Rust. These changes require upstream changes to the extendr library.
> There are other packages that are also affected here. Making these changes
> is a delicate act and requires care and focus. All of the extendr
> developers work full time and cannot make addressing these changes their
> only priority for the next 2 weeks.
Using non-API entry points is a choice that comes with risks. The ones
leading to WARNINGs for your packages (PRSEEN and SYMVALUE)have been
receiving NOTEs in check results for several weeks. Using
tools:::checkPkgAPI you can see that your packages are referencing a
lot of non-API entry points. Some of these may be added to the API,
but most will not. This may be a good time to look into that.
To minimize disruption we have been adding entry points to the API as
long as it is safe to do so, in some cases against our better
judgment. But ones that are unsafe to use will not be
added. Eventually their declarations will be removed from public
header files and they will be hidden when that is possible. Packages
that have chosen to use these non-API entry points will have to adapt
if they want to pass R CMD check. For now, we will try to first have
use of these entry points result in NOTEs, and then WARNINGs. Once
their declarations are removed and they are hidden, packages using
them will fail to install.
> Additionally, a blog post with "examples of moving non-API entry point
uses
> into compliance" would be very helpful in this endeavor.
WRE now contains a section 'Moving into C API compliance'; that seems
a better option for the moment given that things are still very much
in flux. We will try to add to this section as needed. For the
specific entry points generating WARNINGs for your packages the advice
is simple: stop using them.
Best,
luke
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics and Fax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: luke-tierney at uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/