How do I conditionally use R packages in help file examples? - r

I'm an R package author, and I received a notice form CRAN that my package was going to be archived because the packages in my Suggests need to be used conditionally. In my main code, they are used conditionally; I wrote a check.packages() function that throws an error if the package is not able to be loaded. In the examples in my Help files, though, I simply attach the package with library(), which is likely where I made my mistake. The problem arose because a package I included in Suggests was archived.
My question is how do I conditionally use packages in examples in Help files? I tried using
ifelse{\Sexpr{isTRUE(requireNamespace("pkg"))}}{
#Example with pkg
}{
\dontrun{
#Example with pkg
}}
that is, if the package is loadable, display the example as usual, and if not, wrap \dontrun{} around it. This worked when I previewed the Help file, but the CRAN check tells me I can't use \ifelse in examples. If it's important that my examples attach packages in my Suggests, is my only option to wrap \dontrun around all of them, regardless of whether the package can be loaded?

CRAN were happy with a simple if statement in the vignette of one of my packages:
if (requireNamespace('pkg', quietly = TRUE)) {
library('pkg')
# Example with pkg
} else {
message("'pkg' not available")
}
I could be missing something, but I can't see why this approach shouldn't work in examples too; perhaps you would need to add an unloadNamespace('pkg') after the example to clean up?

Related

R not recognizing analyze() function in psycho package?

I'm trying to use the Psycho package to analyze a model. I've tried installing Psycho through CRAN as well as install_github and the installation worked. The package is loaded but the analyze function is not being recognized. I've tried psycho::analyze which also does not work. Following this question I also installed and loaded statnet.common. Any suggestions?
Error in analyze(m2, CI = 95) : could not find function "analyze"
For any future person that comes across this, I was also having problems with the analyze() function. One can use the following solution that worked for me:
> install.packages("remotes")
> remotes::install_github("easystats/report")
> library("report")
> report(m2) # use this instead of analyze()
I had the same issue while trying to follow this tutorial: https://neuropsychology.github.io/psycho.R//2018/05/01/repeated_measure_anovas.html
(and I wish it was updated, unfortunately it still refers to outdated functions).
Potential solutions (alternative library) are discussed on this page: https://github.com/easystats/easystats/issues/58
Unfortunately, I have not managed to get these to work, but other people commented that the solutions worked for them.

Determining if there are unused packages in an R script [duplicate]

As my code evolves from version to version, I'm aware that there are some packages for which I've found better/more appropriate packages for the task at hand or whose purpose was limited to a section of code which I've now phased out.
Is there any easy way to tell which of the loaded packages are actually used in a given script? My header is beginning to get cluttered.
Update 2020-04-13
I've now updated the referenced function to use the abstract syntax tree (AST) instead of using regular expressions as before. This is a much more robust way of approaching the problem (it's still not completely ironclad). This is available from version 0.2.0 of funchir, now on CRAN.
I've just got around to writing a quick-and-dirty function to handle this which I call stale_package_check, and I've added it to my package (funchir).
e.g., if we save the following script as test.R:
library(data.table)
library(iotools)
DT = data.table(a = 1:3)
Then (from the directory with that script) run funchir::stale_package_check('test.R'), we'll get:
Functions matched from package data.table: data.table
**No exported functions matched from iotools**
Have you considered using packrat?
packrat::clean() would remove unused packages, for example.
I've written a command-line script to accomplish this task. You can find it in this Github gist. I'm sure there are edge cases that it misses, but it works pretty well, on both R scripts and Rmd files.
My approach always is to close my R script or IDE (i.e. RStudio) and then start it again.
After this I run my function without loading any dependecies/packages beforehand.
This should result in various warning and error messages telling you which functions couldn't be found and executed. This again will give you hints on what packages are necessary to load beforehand and which one you can leave out.

Using another R package function without using the whole package as dependency

I'm working on an R package here and got this doubt: I need an auxiliar function from another package, but I don't want to include the entire package as a dependency because I only need this one function. What is the correct procedure here? Is it OK if both codes are GPL-2 and I just copy/paste the function to my package? Should I contact the author? Or is it best to include the whole package as a dependency?
If it's just a small function, I don't see a problem with copying the code into your own package (since everything is GPLed). You should acknowledge the source in your package though.
This has the benefit of insulating your code from any changes in the other package; it's not unusual for updates to packages to break other packages downstream. It has the downside that if those updates were useful (bug fixes or added functionality) then you don't benefit from them either.

How can I tell which packages I am not using in my R script?

As my code evolves from version to version, I'm aware that there are some packages for which I've found better/more appropriate packages for the task at hand or whose purpose was limited to a section of code which I've now phased out.
Is there any easy way to tell which of the loaded packages are actually used in a given script? My header is beginning to get cluttered.
Update 2020-04-13
I've now updated the referenced function to use the abstract syntax tree (AST) instead of using regular expressions as before. This is a much more robust way of approaching the problem (it's still not completely ironclad). This is available from version 0.2.0 of funchir, now on CRAN.
I've just got around to writing a quick-and-dirty function to handle this which I call stale_package_check, and I've added it to my package (funchir).
e.g., if we save the following script as test.R:
library(data.table)
library(iotools)
DT = data.table(a = 1:3)
Then (from the directory with that script) run funchir::stale_package_check('test.R'), we'll get:
Functions matched from package data.table: data.table
**No exported functions matched from iotools**
Have you considered using packrat?
packrat::clean() would remove unused packages, for example.
I've written a command-line script to accomplish this task. You can find it in this Github gist. I'm sure there are edge cases that it misses, but it works pretty well, on both R scripts and Rmd files.
My approach always is to close my R script or IDE (i.e. RStudio) and then start it again.
After this I run my function without loading any dependecies/packages beforehand.
This should result in various warning and error messages telling you which functions couldn't be found and executed. This again will give you hints on what packages are necessary to load beforehand and which one you can leave out.

Documentation when Package Name = Main Function Name

I am writing an R package names slidify. The main function in the package is also named slidify. When I run devtools::check, I get a warning that there is a conflict in the Rd files.
I don't want to rename the function, since it succintly conveys what the package is intended for. What is best practice in this situation? Should typing ? slidify lead to the function documentation or package documentation?
Any thoughts would be appreciated.
I'd make a "slidify-package.Rd" file, (or a "slidify-package.R" file with nothing but roxygen comment blocks)
?slidify should lead to the function documentation and slidify?package should lead to the package documentation, and both help pages should have a link to the other (in the seealso section, for example)

Resources