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/
"Stop using them" is pithy advice but far easier said than done! With respect to NOTES and WARN on CRAN, these do not result in any package maintainer notifications. The only notification that the developers receive is the threatening one that states that the packages will be removed from CRAN with a very short timeline. Is there a link you can provide regarding the "Moving into C compliance?" It cannot be found at https://cran.r-project.org/doc/manuals/R-exts.html. Given that there hasn't been a stable release with these changes, how are we to know these changes have been stabilized and begin working towards remedying them? These WARNs come from R-devel which is, as its name suggests, a development version which is vacillating daily. On Tue, Jun 25, 2024 at 12:10?PM <luke-tierney at uiowa.edu> 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 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/ >[[alternative HTML version deleted]]
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 at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >