[I am taking the liberty of Cc-ing the list again because this kind of advice could be useful for other people too.]
Dear Riccardo Di Francesco, В Wed, 15 Mar 2023 08:41:01 +0100 Riccardo Di Francesco <difrancesco.riccard...@gmail.com> пишет: >> Please ensure that your functions do not write by default or in >> yourexamples/vignettes/tests in the user's home filespace (including >> the package directory and getwd()). This is not allowed by CRAN >> policies.Please omit any default path in writing functions. In >> yourexamples/vignettes/tests you can write to tempdir(). > I guess this comes from the configure.R script that writes a Makevars > file that specifies the appropriate C++ version. > Did you experience something like this? The package review is both a defining feature of CRAN and its rate-limiting step. With the number of CRAN packages rising almost exponentially and the burden of responsibility only increasing (various kinds of supply-chain attacks becoming a frequent occurrence over at the more popular NPM and PyPI repositories), there is increasingly more reason for CRAN reviewers to fail safe and reject some false positives. All that is a long way to say that sometimes CRAN reviewers make mistakes. Does the rejection e-mail tell you whether you can appeal? I think it says something like "please reply-all and explain", but make sure to check yourself (i.e. the rules on whether you should reply-to-all or reply-to-sender may have changed). I have argued my way out of a rejection once, but only because there was an easy way to show the mistake on the reviewer's part. Were there any NOTEs about files being left after the R CMD check run (or any other NOTEs or WARNINGs)? Does the rejection e-mail tell you where is the offending write function? Looking at your package, I see the calls to cat(..., file = ...) and writeLines(file = ...). You may need to demonstrate in your reply that they all live under tools/* and are only called during the package configuration. Any other places where you may be writing to files from R code? I also see a cat() call in a summary() method; it's probably not the reason for rejection. There's also the use of std::ofstream in the C++ code under src/*. Is the writeOutput() function used anywhere? You could try to demonstrate that there are no calls to this function, hence there is no way C++ code could write files where it's not welcome to do so. If there's no way to appeal the rejection, that's more problematic because the rules say you now have to submit a version of the package that is different in both the version number and the content. In that case, (assuming there's really no way for the package to write files in user directories) hide the writeOutput() function behind an #ifdef or even remove it if possible (put it on a separate branch if you use it for other purposes elsewhere) and put the rest of the explanation about the code under tools/* in the submission comment. Good luck! -- Best regards, Ivan ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
