I was building a package that I wanted to submit to CRAN. I completed R CMD checks (using devtools::check()) and ensured that I fix all errors, warnings and notes before I build my package (devtools::build) and then submit the resulting tar.gz file to CRAN.
However, apparently, the package failed the R CMD checks at CRAN (There was one note and one error, as per their mail).
Now my question was, why wasn't this picked up when I ran the checks at my end?
To provide some specifics - One of the notes was regarding the usage of a few functions from stats package. I hadn't specifically imported these functions in my namespace.
While this seems to be an easy enough fix, it's mildly irritating (I would have ideally expected to find this while I was running my checks)
How can I avoid such situations in the future?
Thanks!
Related
I updated R using installr and asked to copy my library. (Even though I've never had this work, I keep hoping maybe it will someday as the package gets updated.) Opened up RStudio and, as usual, it can't find any of the packages that were in my old library. I next copied all the files from my old library into my new library, and several critical ones still don't work. For example, when I tried to load tidyverse, the message I receive is:
Error: package or namespace load failed for ‘tidyverse’: package ‘lazyeval’ was installed by an R version with different internals; it needs to be reinstalled for use with this R version.
I tried remove.packages("tidyverse") and then install.packages("tidyverse", dependencies = TRUE), and I still get the same message about the package lazyeval. I tried installing lazyeval, but then, when I go through those same steps again to try to use tidyverse, now it's lubridate that was installed by an R version with different internals.
How can I avoid this incredibly irritating and time-sucking iterative process of trying to install a package, seeing that the internals are wrong for some dependent package, installing whatever package was the problem, installing the package I actually care about, and then figuring out what other dependencies are problems?
The tidyverse package hardly contains anything: its main purpose is to get a bunch of other packages loaded. Removing it and updating it won't help update the other packages. You could do what #phago29 suggested in their comment, but an easier way is just to update everything. Run this command in an R session:
update.packages(ask = FALSE, checkBuilt = TRUE)
A few notes:
If you have admin capabilities, run as admin, and it will update your main library. If you don't, it'll install new copies in your user account.
Even though you're saying ask = FALSE, it may ask some questions about whether you can build packages from source. Answer "Yes" if your system is set up to do that, "No" if not. If you're not sure, try "Yes", and if you get install failures, run it again and say "No".)
This is likely to run for a while, so go away and have a coffee or something.
How often should one update a package on CRAN? I noticed NOTEs in the CRAN checks that I have since solved.
However, I just discovered that the("my"(disclosure)) package now fails to install on one of the Linux flavors. How can I best know what is causing the error as the logs simply show:
installing to library ‘/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages’
Error: ERROR: no permission to install to directory ‘/home/hornik/tmp/R.check/r-devel-gcc/Work/build/Packages’
Secondly, if I fix this problem, how long should I wait before submitting to CRAN? I was ideally thinking of taking a month or so as I read somewhere.
Thanks in advance.
CRAN checks for reference.
EDIT:: I discovered that there are some issues with dplyr as per its CRAN checks, could this be causing the problem?!
One of the most used guidelines for releasing R packages on CRAN says
Do not submit updates too frequently. The policy suggests a new
version once every 1-2 months at most.
I was developing a package when I found a new error when building the package.The error makes reference to a line that previously didn't have any problem and I didn't modify. However it run smoothly in a fresh R session when I ran the code or knit the vignette alone.
Long story short: I found that this error happens when a suggested package (by my package's DESCRIPTION) is loaded before my package.
How can I control this?
The reason of the error is that my package (A) has a function is named exactly the same as the other package (B) because it does the same kind of process, but I use a different name for the same arguments (and in my version I provide other arguments as well). A solution I found is to use A::function, but that would be uglier to the reader. Is there any other solution?
This didn't happened in previous cycles of development. I have observed it on the latest R version R version 3.4.3 (2017-11-30) -- "Kite-Eating Tree" and in the devel version of R. The packages are build using both R CMD build package and devtools::check()
The conflicting package is in Suggests: part of the DESCRIPTION file of the package
This question might be related to this other one.
I am trying to publish my R package. I ran 'check' from R studio and got a clean OK (without Notes or Errors).
After submitting it, I got feedback from CRAN saying that I have NOTES about "no visible global function definition for ‘quantile’"
I re-checked my package on R studio and got a clean OK again. I didn't see this note on my end. Does anyone know why we get different checking results?
Maybe the best place to catch these things today (if your problem is not OS specific) is with win-builder as some people have said in the comments.
The devtools package has a really convenient function to send your package to win-builder, just run build_win() when inside your Rstudio project for the package. It will compile the package and then upload it to win-builder, which will run tests both on the R-release and R-devel and thensend you the link for the results on the email specified on the description file.
This behavior has been part of R-devel since late June this year (see here for details). As it says in the CRAN Repository Policy:
Please ensure that R CMD check --as-cran has been run on the tarball to be uploaded before submission. This should be done with the current version of R-devel (or if that is not possible and explained in the submission, current R-patched or the current release of R.)
So, you need to run R CMD check --as-cran on your package, using R-devel.
I would like to submit a package (DLMtool) to the CRAN repository. When I check the package with R CMD check --as-cran I receive only 1 note regarding the new submission.
However when I submit the package I am receiving feedback from the R core team regarding errors that I do not receive. For example:
Quitting from lines 261-262 (DLMtool.Rnw)
Error: processing vignette 'DLMtool.Rnw' failed with diagnostics:
one node produced an error: NAs are not allowed in subscripted assignments
I cannot recreate this error by running the code myself. But that isn't the point of this post: I'm not worried about specific errors, rather my inability to detect these myself. To this point Prof. Ripley has been very patient. I desperately don't want to waste any more of his time or any of the R core team by using them as a step-by-step checking process.
How can I recreate the CRAN package check process if --as-cran is insufficient?
A similar question has been asked regarding a previous version of R that was not answered satisfactorily as far as I can tell:
CRAN package check finds warning that R CMD check --as-cran doesn't
Cheers,
Tom
I'm using Windows 7 x64, RStudio 0.98.507 and R 3.1.1 x64.
Submitting a package to CRAN still fills me a with a sense of uneasiness, despite having been successful on a number of occasions.
Some things to check:
Ensure you are using the correct process
Specifically, use:
R CMD build pkg
R CMD check pkg_version.tar.gz
Make sure you check using the current version of R, as well as the development branch, R-devel (http://cran.r-project.org/bin/windows/base/rdevel.html)
Submit your package to the windows builder (http://win-builder.r-project.org/)
Make sure you have read, and completely understood, every single sentence of the CRAN submission policy (http://cran.r-project.org/web/packages/policies.html)
Submit your package using the online submission form (http://cran.r-project.org/submit.html)
Then hope for the best.
To be honest, every individual I have dealt with on the CRAN build team have been very patient and helpful.