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. *Can we extend this very short notice to handle the Non-API changes before removal from 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. Additionally, a blog post with "examples of moving non-API entry point uses into compliance" would be very helpful in this endeavor.
Non-API updates
8 messages · iuke-tier@ey m@iii@g oii uiow@@edu, Josiah Parry, Tomas Kalibera +3 more
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/
On 6/25/24 18:25, Josiah Parry wrote:
"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.
https://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Moving-into-C-API-compliance Tomas
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]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
On 2024-06-25 12:25, Josiah Parry wrote:
"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]]
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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
On 25/06/2024 17:25, Josiah Parry wrote:
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.
I'd recommend regularly checking https://cran.r-project.org/web//checks/check_results_josiah.parry_at_gmail.com.html on a regular basis or better still automating said checking. I use dang::checkCRANStatus() in my .Rprofile? to stay up to date ... R> dang::checkCRANStatus("josiah.parry at gmail.com") ??????? Package WARN NOTE OK 1??????? arcgis?????????? 13 2 arcgisgeocode???????? 8? 5 3? arcgislayers?????????? 13 4? arcgisplaces???????? 9? 4 5?? arcgisutils??????? 13 6??????? arcpbf??? 2??? 7? 4 7?????????? b64??? 2??? 7? 4 8???????? rsgeo??? 2??? 7? 4 9?????? trendyy?????????? 13 Tim
On 25 June 2024 at 12:25, Josiah Parry wrote:
| 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. https://rstudio.github.io/r-manuals/r-exts/The-R-API.html#moving-into-c-api-compliance That's the prettified quarto rendering, and it uses the dev version, so Luke's new section is there. Of course, the R Projects also has a site with the manuals rendered for r-release and r-devel. Dirk
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org