Thank you for such a quick reply, Gabriel, I am not too familiar with the package tools, so cannot speak too confidently, but below is how I see the issue currently.
The issue is not for external packages to rely on unexported functions from tools::, rather the issue is that 'R CMD check —as-cran' runs those functions from tools:: in order to check the validity of Rd files (from any package). R 4.3.0 added @ as internal S3 generic. However, package tools does not recognise it as valid in Rd files and throws errors when it sees S3 method declared for @ in the Rd usage lines. So any package that will try to use @ generic will run into the issue, without attempting to use internal S3 functions in their code, but during the R CMD check step. Hope I am being clearer now, and not missing something important (all these things: both @ as generic and tools:: package are quite new to me), Karolis K. > On Apr 29, 2023, at 12:38 AM, Gabriel Becker <gabembec...@gmail.com> wrote: > > Karolis, > > It seems likely, without having looked myself, that you could be correct > about the issue, but it does seem worth noting that both of the functions you > have mentioned are not exported, and thus not part of the API that extension > packages are allowed to use and rely on. > > If retrieving the list of "internal S3 generics" is something package and > user code is allowed to do, the real fix seems to go beyond what you're > suggesting, to actually providing an API entry point that gives the relevant > information (maybe in an identical form to how those internal functions do > so, maybe not). If it's not, for some principled reason, something R-core > wants to support package and user code doing, then the fact that the new > thing doesn't work automatically with roxygen2 would become the roxygen > maintainers' job to fix or document. > > I do not know whether R-core feels this is something packages/users should be > able to do; both decisions strike me as possible, to be honest, depending on > details I don't know and/or am not privy to. > > Best, > ~G > > On Fri, Apr 28, 2023 at 1:49 PM Karolis Koncevičius > <karolis.koncevic...@gmail.com <mailto:karolis.koncevic...@gmail.com>> wrote: >> This issue might go deeper - I was not successful in passing R CMD checks >> for the usage files. R CMD check kept showing errors for `@` declarations, >> even thou they were identical to `$` declarations (which passed fine). >> >> Seems like the usage check functions are not prepared for `@` - also in >> tools:::.S3_method_markup_regexp >> >> > On Apr 28, 2023, at 10:34 PM, Karolis Koncevičius >> > <karolis.koncevic...@gmail.com <mailto:karolis.koncevic...@gmail.com>> >> > wrote: >> > >> > I was building a package that uses the new generic @ and kept having >> > errors with “roxygen2” documentation. “roxygen2” generated NAMESPACE added >> > `@.newclass` as a newly exported function, not as a S3method. >> > >> > At first I thought this must be a bug in roxygen2 and they lag behind the >> > new developments in R. But after some investigation I found that >> > “roxygen2” is using tools:::.get_internal_S3_generis() to decide if the >> > method should be exported as S3method or not. For some reason “@<-“ is >> > listed in there, but “@“ is not. >> > >> > Am I missing some context, or is this an oversight? >> > >> > Kind regards, >> > Karolis Koncevicius >> >> ______________________________________________ >> R-devel@r-project.org <mailto:R-devel@r-project.org> mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
