In an effort to streamline our NAMESPACE, we moved from blanket 'import(methods)' to specific importFrom(methods, ....) for the objects we specifically needed. Doing so broke a downstream package, however, which has this directive: importFrom(data.table,`.__T__[:base`) That package stopped installing after the above change. I can get it to install again by adding: importClassesFrom(methods, "[") to our package, but I'm not sure why this would be necessary. I'm still left with two questions: 1. How did we end up with ".__T__[:base" in our exports when we don't do any S4 around '[' in the package (we do export S3 methods on it)? 2. Is there any legitimate reason for a package to try and import such an object? In other words, is breaking this downstream package by not adding the 'importClassesFrom' workaround the right thing to do? I don't see any other CRAN packages with a similar directive in its NAMESPACE. Michael Chirico
[R-pkg-devel] Removing import(methods) stops exporting S4 "meta name"
4 messages · Michael Chirico, Duncan Murdoch, Richard M. Heiberger +1 more
To save others a bit of time, the package in question is "do", and Michael has already posted an issue on their Github page asking why they made this import: https://github.com/yikeshu0611/do/issues/1 . And if you remove that import and run R CMD check on "do", it fails with this error: * checking examples ... ERROR Running examples in ?do-Ex.R? failed The error most likely occurred in: > ### Name: join > ### Title: Join two dataframes together > ### Aliases: join join_inner join_full join_left join_right join_out > > ### ** Examples > > df1=data.frame(x=rep(c('b','a','c'),each=3), + y=c(1,3,6), + v=1:9) > > df2=data.frame(x=c('c','b','e'), + v=8:6, + foo=c(4,2,1)) > join_inner(df1,df2,'x') Error in xj[i] : invalid subscript type 'list' Calls: join_inner -> data.frame -> [ -> [.data.table -> [.data.frame Execution halted I'm pretty sure that import should not be made, but I don't know the intention of this example, or what the correct fix would be. Duncan Murdoch
On 14/03/2024 2:34 p.m., Michael Chirico wrote:
In an effort to streamline our NAMESPACE, we moved from blanket 'import(methods)' to specific importFrom(methods, ....) for the objects we specifically needed. Doing so broke a downstream package, however, which has this directive: importFrom(data.table,`.__T__[:base`) That package stopped installing after the above change. I can get it to install again by adding: importClassesFrom(methods, "[") to our package, but I'm not sure why this would be necessary. I'm still left with two questions: 1. How did we end up with ".__T__[:base" in our exports when we don't do any S4 around '[' in the package (we do export S3 methods on it)? 2. Is there any legitimate reason for a package to try and import such an object? In other words, is breaking this downstream package by not adding the 'importClassesFrom' workaround the right thing to do? I don't see any other CRAN packages with a similar directive in its NAMESPACE. Michael Chirico
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
this looks like a relative of the issue I tripped on that is discussed in the email threads https://stat.ethz.ch/pipermail/r-package-devel/2024q1/010531.html https://stat.ethz.ch/pipermail/r-devel/2024-March/083259.html At issue is the default export of exportPattern(".") System generated names, which is what ".__xxx__" looks like, seem to be the issue. I can't make any specific recommendations behind connecting this current issue to my recent experience. Rich
On Mar 14, 2024, at 14:34, Michael Chirico <michaelchirico4 at gmail.com> wrote: importFrom(data.table,`.__T__[:base`)
On Thu, 14 Mar 2024 16:06:50 -0400
Duncan Murdoch <murdoch.duncan at gmail.com> wrote:
Error in xj[i] : invalid subscript type 'list' Calls: join_inner -> data.frame -> [ -> [.data.table -> [.data.frame Execution halted
And here's how it happens: join_inner calls xi[yi,on=by,nomatch=0] on data.tables xi and yi. `[.data.table` calls cedta() to determine whether the calling environment is data.table-aware. If the import of `.__T__[:base` is removed, cedta() returns FALSE. `[.data.table` then forwards the call to `[.data.frame`, which cannot handle data.table-style subsetting. This is warned about in <https://cran.r-project.org/package=data.table/vignettes/datatable-importing.html#data-table-in-imports-but-nothing-imported>; the 'do' package should have set the .datatable.aware = TRUE marker in its environment. In fact, example(join_inner) doesn't raise an error with the following changes when running with data.table commit f92aee69 (i.e. pre-#6001): diff -rU2 do/NAMESPACE do_2.0.0.0.2/NAMESPACE --- do/NAMESPACE 2021-08-03 12:37:00.000000000 +0300 +++ do_2.0.0.0.2/NAMESPACE 2024-03-15 14:01:10.588561222 +0300 @@ -130,5 +130,4 @@ export(upper.dir) export(write_xlsx) -importFrom(data.table,`.__T__[:base`) importFrom(methods,as) importFrom(reshape2,melt) diff -rU2 do/R/join.R do_2.0.0.0.2/R/join.R --- do/R/join.R 2020-06-30 06:47:22.000000000 +0300 +++ do_2.0.0.0.2/R/join.R 2024-03-15 13:54:02.289440613 +0300 @@ -1,2 +1,4 @@ +.datatable.aware = TRUE + #' @title Join two dataframes together #' @description Join two dataframes by the same id column.
Best regards, Ivan