[Rd] [External] Non-API updates

[J C Nash]

It is probably important to note that the WRE with the new section on C API compliance is
in the R-Devel docs, not the current ones.

JN

On 2024-06-25 12:10, luke-tierney--- via R-devel wrote:
> 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 using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>