Today I have tried to prepare a new CRAN update for a package and have come across a warning, while performing devtools::check().
Since this warning also occurs without my changes I made to the package, I am assuming this is a new check. Unfortunately I don't really get what I am supposed to do.
This is the error message:
A complete check needs the 'checkbashisms' script.
See section ‘Configure and cleanup’ in the ‘Writing R Extensions’
manual.
Of course I took a look at the section ‘Configure and cleanup’ as proposed in the warning. But still, I am not sure what to do exactly. I got, there is a checkbashisms Perl script I can download somewhere on the internet (but this alone won't make this message disappear). How shall I integrate this, that the message actually disappears.
Any hints or comments would be extremely helpful to me.
Here is a link to the repo of the package in case you want to clone it to reproduce the error.
Related
I'm currently doing some work on a package, and calling devtools::check() is producing the following warning:
❯ checking Rd files ... WARNING
NULL
However, when manually inspecting each of the .Rd files created by devtools::document() and re-reading the documentation, I don't see why this warning is appearing. I know it's only a warning and doesn't impact the functionality of the package, but I can't figure out where this is coming from.
Any help is greatly appreciated.
This rig-related bug has been fixed with version 0.5.2, see r-lib/rcmdcheck#184 on GitHub. #rossdrucker9 I am well aware that you already know about this.. just want to write it down for future generations that end up here first (like I did).
I submitted a package to CRAN and they asked me to replace \dontrun{} by \donttest{} in the Rd-files and resubmit. I was using \dontrun{} to wrap some examples that are supposed to throw error messages.
After replacing \dontrun{} by \donttest{} I conducted some tests and R CMD check still succeeds but it happens that now both devtools::check() and R CMD check --as-cran fail due to the examples wrapped in \donttest{}:
checking examples with --run-donttest ... ERROR
After some browsing I learned that R 4.0.0 has changed R CMD check --as-cran to run \donttest examples. According to the NEWS of R-devel:
"R CMD check --as-cran now runs \donttest examples (which are run by example()) instead of instructing the tester to do so. This can be temporarily circumvented during development by setting environment variable R_CHECK_DONTTEST_EXAMPLES to a false value."
Since I intend to resubmit the package to CRAN, setting _R_CHECK_DONTTEST_EXAMPLES_ to false locally will not help me.
I also found this recent discussion in a devtools issue where Hadley Wickham states that:
"Generally, now if you don't want to run tests on CRAN \dontrun{} is more likely to work, but using \dontrun{} may cause initial submission to fail."
So now I don't know how to proceed because if I resubmit the package with the required changes I already know it will throw an error in R CMD check --as-cran, and hence it will probably fail CRAN's automatic pretests.
EDIT:
As suggested here I tried if(interactive()){} instead of \dontrun{}. This solution succeeds in R CMD check --as-cran and devtools::check() but I don't think it is the most appropriate way to address this problem since it does not work well with example() (throws an error and does not show the remaining examples). \dontrun{} works better with example() as it prints all the examples but comments out the ones wrapped with \dontrun{}.
If you know that something will throw an error, you can wrap it in try().
## example of failing code
try(stop("Here is an error"))
I don't think the package examples are the right place for "examples that are supposed to throw error messages".
Your problem would be easily solved when you move these 'examples' to testthat unit tests.
There is
expect_error()
expect_warning()
to see if your package throws a warning/error as expected.
If you really want to inform users about what they should avoid to input, maybe you can just add it as a comment to the examples or into the other documentation (details, param)
What you see quite regularly in other package examples is the following:
## Example for working
function(x, abc = "5)
## This would give an error because
# function(x, abc = "falsch")
## Working example 2
function(x)
x <- x+y
My paths and files are as follows ...
E:R/R-2.15.1/library/Rcmdr/
E:R/R-2.15.1/library/RcmdrPlugin.Package/
E:R/R-2.15.1/MyLibrary/RcmdrPlugin.Package.zip
E:R/R-2.15.1/MyLibrary/RcmdrPlugin.Package/
where, in the name RcmdrPlugin.Package, I've used the word 'Package' to represent the name of the actual package being used.
The installation is as described above because (i) I'm not an expert at installing packages, (ii) I couldn't do a direct install from Cran because I wanted to put the package onto a USB stick; and, (iii) at work the Cran server is blocked (sic).
When I start the package from the GUI the Cmdr opens once and quickly closes (I don't know if this is relevant or normal) and opens again. Once open, I can operate the package via the Cmdr interface. It's a very nice package, everything works really well until I want to save the work. Then I get the following error,
Error in obj[i] : object of type 'closure' is not subsettable
I've been in contact with the people who developed (and are still developing) the package and they cannot reproduce the bug.
I strongly suspect that the problem lies in my 'crappy' install and file configuration, rather than with the package.
Can anyone please help me by suggesting how I would undo what I've done and do it properly in view of the constraints list above?
I appreciate that I can use Remove to get rid of the package but I don't want to start tinkering with something without having a greater understanding of what I'm doing.
Lastly, note that is error has been discussed a number of times on this list but not within this particular context.
I've managed to get it to work by following the instructions from here stackoverflow.com/questions/12820189/… where I set repos=NULL after I'd put the package into /MyLibrary/
I tried to run a Bioconductor package (truncateCDF) that modify an environment(hgu133plus2cdf), to remove unwanted probesets, from an affymetrix chip.
Everything went fine, until I got the following message (translated from french):
> assign(cdfname, cdf.env, env=CDF.env)
Error in assign(cdfname, cdf.env, env = CDF.env) :
impossible to change the value of a locked link for 'hgu133plus2cdf'
The assign function is the ultimate function of the code, that save the changes made to the environment dataset CDF.env to the original environment (hgu133plus2cdf), before using it in analyses of affymetrix chip results; so, it is essential.
My question: what is this locked link to the hgu133plus2cdf environment, and how could I bypass it.
The author of this package successfully run its package around 2005; so I suppose it is a feature introduced since then in R (probably not related to Bioconductor, since assign is a basic R function, reason why I ask this question on this forum instead of Biostar).
I tried to read the docs, but I am overwhelmed, when it comes to environments.
Thanks in advance for any help.
I don't think truncateCDF is from a Bioconductor package; it is a at least not current. This sounds like this post and the next two from the same thread from the Bioconductor mailing list. It is a result of a change in R -- packages now have not-easily-modified name spaces, and these are implemented by locking the environment in which name space symbols are defined. Removing probes is not an essential part of a typical microarray work flow. Please ask on the Bioconductor mailing list (no subscription required) if you'd like more help.
I am using a code where at some point i have something like that
anna <- DNAStringSet()
for (chr in c(paste('chr',seq(1,22),sep=''),'chrX','chrY')){
.
.
.
anna.view<-DNAStringSet(Views(unmasked(Hsapiens[[chr]])
.
anna<-append(anna,anna.view)
}
gc()
}
anna
library(rGADEM)
gadem <- GADEM(anna, genome = Hsapiens)
Warning message:
Using XStringViews() on a character vector is deprecated.
Please use instead something like:
as(DNAStringSet(x)), "Views")
if you really want views, otherwise just:
DNAStringSet(x)
What does that message mean? Do i have to change anything in my code, or it is safe to continue?
The warning about XStringViews being deprecated warns you that you can use this function, although it is discouraged because better alternative exist (the alternatives are suggested in the warning). However, you can still use the function.
I think the code that generates the warning comes from a function within a package. But without a reproducible example, this is hard to say. If the warning is generated from a package, upgrade to the newest version to see if that fixes the problem (although the package does not look like it is actively maintained). Alternatively, you mail the package maintainer and tell about this issue.
Bottom line, you can still use the package in your research, the warning relates to a purely software technical issue. There is no garantuee however that the code will run in new versions of R or Bioconductor, as deprecated code has a tendency to be deleted at some time.