I have a simple shell script that builds my Roxygen documents, builds the package, checks, then installs the newly built package on my machine. It's quite simple:
#! /bin/sh
R CMD roxygen -d myPackage
R CMD build myPackage/
R CMD check myPackage_0.01.tar.gz
R CMD INSTALL myPackage myPackage_0.01.tar.gz
But I'm having issues with Roxygen picking up my .onLoad() function as described previously on StackOverflow. The solution is to use the use.Rd2=TRUE option with roxygenize. Well I want to build from the command prompt so I changed this line
R CMD roxygen -d myPackage
to the following line which shoves a roxygenize line to R through the stdin:
echo 'require("roxygen"); roxygenize("myPackage", roxygen.dir="myPackage",
copy.package=FALSE, use.Rd2=TRUE)' | R --no-save < /dev/stdin
This seems to work just dandy. But it feels a little convoluted. Is there an easier and/or more elegant way?
I do something similar, but I use a HERE document in the shell script to make it look cleaner.
#!/bin/sh
##
##
## Must be run from the parent of the package directory (no options
## to change target of check or tarball!?!)
PACKAGE="analyzeNMON"
VERSION=$(awk -F": +" '/^Version/ { print $2 }' ${PACKAGE}/DESCRIPTION)
R --no-restore --slave <<EOR
library(roxygen)
roxygenize(package.dir="${PACKAGE}",
roxygen.dir="${PACKAGE}",
use.Rd2=TRUE,
overwrite=TRUE,
copy.package=FALSE,
unlink.target=FALSE)
EOR
R CMD build ${PACKAGE}
R CMD check ${PACKAGE}_${VERSION}.tar.gz
R CMD INSTALL ${PACKAGE}_${VERSION}.tar.gz
The R code is very similar to that in the script run during R CMD roxygen.
The roxygen that is installed on my system (version 0.1; installed from CRAN this week) doesn't seem to support the -s option mentioned above...
May be the R CMD roxygen -s option will help here. I believe it is effectively the same as setting use.Rd2=TRUE in the roxygenize function.
Related
I want to install rJava but this fails with the following suggestion:
Make sure you have Java Development Kit installed and correctly registered in R.
If in doubt, re-run "R CMD javareconf" as root.
ERROR: configuration failed for package ‘rJava’
* removing ‘/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rJava’
* restoring previous
‘/Library/Frameworks/R.framework/Versions/4.0/Resources/library/rJava’
Hence, I follow this suggestion (and the one everyone else seems to suggest) and run R CMD javereconf in the terminal but now I get the message that zsh: command not found: R.
How can I get R CMD javereconf to work?
Thanks.
EDIT: While I followed the blogpost suggested by #Till, I still struggle to run R CMD javereconf (same error). In the meantime, I figured that I should mention that I'm using MacOS Big Sur with an Apple M1 Chip.
When typing R.home() RStudio returns /Library/Frameworks/R.framework/Resources/R.
There is currently a bug in CRAN's R installation package that results in it not correctly installing symbolic links to R and Rscript for commandline use. I've just verified this by inspecting the postflight script in their 4.0.5 installation package.
Basically, there's a problem wherein the uname check doesn't know about operating system releases of 20 and above.
If your uname -r release version is over 20, this would explain why the installation silently failed. My recommendation would be to manually create the symbolic links the package is supposed to create by doing something like this:
if uname -r | grep '^2' >/dev/null; then
## 15.0 and higher don't allow messing with /usr/bin
## so use /usr/local/bin instead
if [ ! -e /usr/local/bin ]; then
mkdir -p /usr/local/bin
fi
cd /usr/local/bin
# create convenience links to R and Rscript
rm -f R Rscript
ln -s /Library/Frameworks/R.framework/Resources/bin/R .
ln -s /Library/Frameworks/R.framework/Resources/bin/Rscript .
fi
I'm going to file a bug with R-project shortly.
Find the location of R and Rscript on your disk by running R.home() on Rstudio's R console.
Then, follow this guide and copy the returned location from R.home() and paste on a new line on /etc/paths.
Then, restart the terminal and run R CMD javareconf
When I enter R CMD ... in my Linux terminal, I receive a dialog to choose the version of R I'd like to run:
$ R CMD
Available Versions:
------------------------
3.4.0
3.4.1
3.4.2
3.4.4
3.5.0
3.5.1
3.5.2
3.5.3
3.6.0
3.6.1
4.0.2
Enter The R Version You'd Like To Run:
Is there an easy fix to this from the command line?
Issue recognized by #MrFlick below
The choice of R versions comes from a non-standard wrapper around the R command:
$ which R
alias R='/opt/rVersionSelect.sh'
/opt/rVersionSelect.sh
Here is the script, in which you can see the selection mechanism:
$ head -500 /opt/rVersionSelect.sh
#!/bin/bash
RDIR=/opt/R
echo "Available Versions:"
echo "------------------------"
for rVer in $RDIR/* ; do
echo $(echo $rVer | cut -d- -f2)
done
read -n 5 -p "Enter The R Version You'd Like To Run: " RunThisVersion
if [ -d $RDIR/R-$RunThisVersion/ ] ; then
echo "Loading $RunThisVersion...."
wait 10
clear
$RDIR/R-$RunThisVersion/bin/R --interactive
else
echo "Unrecognized Version: $RunThisVersion"
fi
As it turns out, the R in R CMD needs to point to one of the many R versions installed. For example, /opt/R/R-3.5.3/bin/R CMD.
For the R in R CMD, it looks like I need to point to one of the many installations of R. For example, /opt/R/R-3.5.3/bin/R CMD INSTALL rJava gives me the same result in the Terminal as using Build, Install and Restart in Rstudio.
When I try to write a custom build script like R CMD javareconf, it fails to execute in RStudio. But /opt/R/R-3.5.3/bin/R CMD javareconf successfully executes in the Terminal.
The way I've dealt with it is to go into the RStudio instance, open a project, and Configure Build Tools. Then I could achieve the same objectives using options from the Build menu. I think this question has merit, because difficult R package installations will suggest using R CMD ... to make the installation work.
I am writing an R package and build and test it with:
Rscript -e "devtools::document()" && R CMD build . && Rscript -e "devtools::test();devtools::check()"
I get a note:
checking top-level files
Non-standard file/directory found at top level:
‘PosteriorBootstrap_0.0.1.tar.gz’
I get the note whether devtools::check() comes first or second.
This
thread suggests:
The note is telling you that you usually shouldn't have a file called
build in the top level of your package.
The tar.gz file is created by R CMD build and I get the same error even if I delete it before running it.
This
thread
suggests adding the tar.gz file to .Rbuildinore, which removes the note.
Another way to remove it is to run everything from devtools:
Rscript -e "devtools::document(); devtools::build(); devtools::load_all('.'); devtools::test(); devtools::check()"
And then I don't get that note.
What's the difference between R CMD build and devtools::build() and why does the former throw that note?
You are combining a number of steps that perform similar and/or competing functions. I would suggest reading this for a best-practice build and check workflow.
When you run R CMD build it builds the package to the current directory, which is the top level package directory. Therefore, when you run your checks, it sees the .tar.gz file in the package root, which is a non-standard file to have in a package, thus the warning. devtools::build() is smart and builds the package to the package parent directory (regardless of where you are calling it from). Trying to call R CMD commands mixed with devtools functions can create issues, because devtools also calls R CMD commands, so you may be duplicating actions at various points in time or causing commands to be called in the incorrect order.
Per the link above, a best-practice workflow would be:
Rscript -e "devtools::document();devtools::check();devtools::build()"
called from the package root, and you avoid dealing with R CMD altogether. If you want to use R CMD it would look something like this:
Rscript -e "devtools::document()" && cd .. && R CMD build PosteriorBootstrap && R CMD check PosteriorBootstrap*.tar.gz
starting in the package root and then changing to the parent directory.
I wonder what would be the best way of testing multiple packages. Let's say we have two local packages:
src/pkg1
src/pkg2
The package pkg1 has a dependency on pkg2. I test all packages using R CMD check in the makefile:
for pkg in src/*; do \
R CMD check $$pkg
Which fails because of the missing dependencies. For example in Java you can include all missing code in the path. I can install first all R src/pkgs but this will leave artifacts on the end of the test in the R.
Is there any recommended way to perform such tests in R or installing all packages is the only solution? Maybe there is a way to use a specific folder for tests only so no other already installed packages would be affected?
Turns out I can use "-l" flag with both
R CMD INSTALL -l /path
and with
R CMD check -l /path
That should solve the problem but won't really cover the issues with more complex inter-dependencies.
According to the document Writing R Extensions ss 1.3 "R CMD check and R CMD build run R with --vanilla, so none of the user's startup files are read".
This doesn't seem to happen on my installation. I have found that my version of R (2.15.1 on Mac) loads the packages in my .Rprofile - i am pretty sure about this, as i've managed to reliably break it by adding library(hobblegobble) to my .Rprofile.
does this matter? If so, should i always prefer to build packages with
R --vanilla CMD build
thanks
You can use either R --vanilla CMD build myPackage or R --vanilla CMD INSTALL --build myPackage if your .Rprofile loads packages that you are trying to build (or install).
The only drawback I am aware of to using --vanilla is that the terminal's completion (i.e. having the package directory name completed for you when you tap tab) may not work while you're typing the path to the package directory.
However, a better solution may be to wrap if (interactive()) {} around code in your .Rprofile that you only want to be run in interactive sessions. e.g. library or require calls.
In your case if your .Rprofile had if (interactive()) library(hobblegobble) you wouldn't need to use --vanilla.