I am trying to check a package that I have built (with vignette) using R CMD check --as-cran [my package] in my windows command prompt. All goes well until I get the message,
WARNING 'qpdf' is needed for checks on size reduction of PDFs
I have downloaded qpdf, put the unzipped folder in my program files directory, and added the bin folder to the PATH.
Not quite sure what else I need to do? I have the feeling I have not installed qpdf correctly or I need to build this program itself? I have read through the readme files and manual for qpdf which appear to be more aimed at unix users (which I have no experience with... I am your standard/regular windows user with little to no programming experience outside of statistical languages). I have had a go at trying to build qpdf using cgywin, but ended up failing to install zlib and prec. Any tips?
I would try
Sys.which(Sys.getenv("R_QPDF", "qpdf"))
Sys.getenv("PATH")
to establish that R is really not finding the qpdf executable, and see where it is looking. You probably shouldn't need to rebuild everything, just figure out why R is not finding the qpdf executable ... does running qpdf from a terminal window work ... ? How are you starting R, and did it have a chance to get the new PATH definition (i.e. do you need to open a new terminal window, or ?? reboot ??)
The incantation above was extracted from tools::compactPDF, from the default value of the qpdf argument, on a Linux machine. You should check for yourself, in case (e.g.) the Windows version is looking for qpdf.exe rather than qpdf ...
There are a couple of other things to consider on a Windows machine:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 7.0 is listed here).
Once you have extracted the zipped qpdf directory to your hard disk, perhaps under C:\Program Files\, added C:\Program Files\qpdf-version_number\bin to your system PATH under the environment variables, and re-launched R, Windows needs to establish that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning, as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. This done, Windows will recognize the file as safe to run and allow other software, including R, to use it.
Recent developments: If you install Rtools 3.5 qpdf is included and that warning is gone. Rtools is a toolset for building packages on Windows and is recently reworked by Jeroen Ooms.
More information : https://cran.r-project.org/bin/windows/Rtools/
Note that the changelog is incomplete, as Rtools 3.5 isn't frozen yet at the time of writing (2019-03-01). Even though it's not visible on the page yet, qpdf.exe is included in the bin directory after installation.
After installing the latest version of RTools, the warning still popped up.
However, I noticed that the Windows "where" command gave two paths to qpdf (different versions). After removing the R_QPDF environment variable and removing the new install of qpdf from the Windows path, so that only qpdf in RTools was found, the warning disappeared.
I got the same warning on Ubuntu so here's a Ubuntu solution for completeness:
First update packages
sudo apt update
Then install qpdf with
sudo apt install qpdf
Tested on Ubuntu 20.04.
Related
For many R packages I try to install (on my Windows 10 machine), I get a warning:
> install.packages('rstan')
WARNING: Rtools is required to build R packages but is not currently installed. Please download and install the appropriate version of Rtools before proceeding:
I thought this was just an erroneous error message since the installation seemed to proceed anyway, but recently I tried to install a package (rstan) and found it completely nonfunctional. My hunch is that since rstan relies completely on compiling code with rcpp, maybe I only got away with the previous packages because I wasn't using the functions in them that relied on Rtools.
I reinstalled Rtools 4.0, and devtools::find_rtools() returns TRUE. But when I run Sys.getenv()['PATH'] there is no Rtools on the path. There isn't a place in the installation process to tell it I want Rtools on the path either, so these instructions don't help - the menus they refer to don't exist for me. So I thought this might be an issue where the new Rtools 4.0 doesn't put itself on the system path. But the problem persisted even after I directly edited the Windows path environment variables (both system and user versions) to include the path given to me by pkgbuild::rtools_path() (C:\rtools40\usr\bin, a path which both exists and appears to be correct).
This doesn't seem to be the same problem as Rtools 4.0 (Rstudio falsely claims it was deleted), since there are no claims Rtools was deleted. It's also not the same as Rtools not being detected by R as far as I can tell: I'm not leaving any features out of my Rtools installation - I'm not even getting the option to in my install wizard.
Would appreciate any advice or recommendations.
Rtools40 requires that you add its bin directory to your PATH variable. The full instructions are here.
You can update your ~/.Renviron file with any of the following methods:
You can do that manually by opening ~/.Renviron and putting the following in it:
PATH="${RTOOLS40_HOME}\usr\bin;${PATH}"
You can also use R (Gui or RStudio or Shell) with the following:
writeLines(
'PATH="${RTOOLS40_HOME}\\usr\\bin;${PATH}"',
con = file("~/.Renviron", open = "a")
)
Both of these methods require a restart of R.
Does anyone have a link to clear instructions on how to install and configure the necessary latex packages to build R packages on a mac?
I have some scripts for building and checking R packages on a mac server. They seemed to work fine, but after upgrading to R 3.1.3, many of the packages started failing with
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'networkVignette.tex' failed.
Messages:
sh: /usr/local/bin/texi2dvi: No such file or directory
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
I found a thread which seemed to suggest I need a more recent version texinfo (5.2) than what is installed by default. And apparently I've I've got the wrong version installed in the wrong location?
which texi2pdf
/sw/bin/texi2pdf
texi2pdf --version
texi2pdf (GNU Texinfo 5.1) 5234
(same version is reported when running system('texi2pdf --version') in R )
This thread gives a link to a texinfo 5.2 source collection:
http://r.789695.n4.nabble.com/R-CMD-build-looking-for-texi2dvi-in-the-wrong-place-R-devel-td4701706.html
But I'm not familiar with installing executable from a tar.gz file on a mac. The R mac help pages I found suggest installing MacTex, which I tried but that didn't seem to help.
** Update: ** additional discussion of related problems on R-SIG-mac mailing list:
https://groups.google.com/forum/#!topic/r-sig-mac/xjyuFdl5Ezk
Update:
Here is where I'm currently at:
I removed my /sw directory to uninstall fink and all of its packages (couldn't figure out how to upgrade it)
installed homebrew
brew install texinfo installs version 5.2 the package,
but generates the message This formula is keg-only, which means it was not symlinked into /usr/local and actually installs in in /usr/local/Cellar/texinfo/5.2/bin which means it is not on the path and R won't find it.
manually symlink each of the texi2pdf, texi2dvi , etc as vincent suggests (this is because R has the /usr/local/bin location as default in the tools::texi2dvi function?
edited the /etc/paths file on the system to add /usr/local/bin so that finds the brew installed 5.2 version before it finds it before the osx system supplied version 4.6 version. This may not be necessary because R has it hardcoded?
All of this gets rid of the "can't find texi* errors", and gives me a bunch of latex errors (which I don't see on unix and windows builds) so I'm still kind of stuck.
This seems very hackish, so there must be a cleaner way? But it sounds like stuff with tex and mac is very sketchy at the moment? https://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
This worked for me on Mavericks and on Yosemite:
ln -s /usr/bin/texi2dvi /usr/local/bin/texi2dvi
ln -s /usr/bin/texi2pdf /usr/local/bin/texi2pdf
On my Lion system both the command which texi2pdf at a Terminal/bash prompt and from a R.app GUI prompt tell me that I have that program in:
system("which texi2pdf")
#/opt/local/bin/texi2pdf
That is a location typical for MacPorts installation. I think the /usr/local/bin/ is what the binary R version "expects". I'm not really that UNIX savvy, but I think the you can modify the PATH environment variable so that R will be able to find your installation. (Whether it will be compatible I cannot say since so much detail is missing from your question.) My Tex installation is MacTex, which I got from https://www.tug.org/mactex/. I admit to having a cobbled-together system:
system("echo $PATH")
# /opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
That gets set at the beginning of an R session because this is the first line in my .Rprofile-(invisible)file:
Sys.setenv(PATH="/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin")
I think /sw/bin/ installations signify a fink install, which I have had very little success with. Simon Urbanek suggests not using any package installers, but then leaves the rest of us UNIX weenies very little in the way of worked examples of how to install that various external packages that underpin the many interesting and oh-so-useful R packages. So I feel your pain, but I'm not running for President.
So I suppose you could try this at your R console before again attempting one of the earlier unsuccessful installs:
Sys.setenv(PATH=paste( Sys.getenv()$PATH, # should be the character string of the $PATH
"/sw/bin/", sep=":")
)
Wish I could offer guarantees, but if it breaks the only guarantee is that you get to keep all the pieces.
I ran into a similar error message using Mavericks 10.9.5 (factory configured) and R 3.1.
It turns out that I didn't have pdfLaTex. I went to this page: http://tug.org/mactex/ and downloaded the MacTex installation package. It's big (>2GB) but after I installed it, my R package build problems went away.
Hope this might be helpful to anyone else who runs into this error message.
I just made the switch from Windows to Ubuntu. In windows I had the possibility to change the R version used in Rstudio IDE with Tools -> Global options -> R versions.
This is not possible in Ubuntu in the same way, indeed the R versions menu does not appear in Ubuntu version of RStudio (why??). Could you help me in finding the good solution for switching among different, already installed versions of R, in Ubuntu?
The switch among different versions is important for satisfying packages modifications and making old scripts working.
I apologize was not a great question, but more of the kind: "please help me, I'm desperate, I've loose all my Windows habs!" ;)
So if anyone like me want to make the switch from Windows to Ubuntu here is how you can compile an older R version and switch between versions using RStudio. As already #Andrie commented out here are some informations, however not complete https://support.rstudio.com/hc/en-us/articles/200486138-Using-Different-Versions-of-R.
You already have the R version provided by Ubuntu Software Center or a more recent version but you need an older version to run an old important script?
First you need to compile the desired R version from source. In Ubuntu updating R to a newer version leave you with one only version (the updated ones) and not two the older and the new like in Win.
Let's go to the shell and install all you need to build R from source
sudo apt-get build-dep r-base
to install all libraries you will need for compiling. (look also here http://cran.us.r-project.org/bin/linux/ubuntu/)
Download the version you need on CRAN
/bin/linux/ubuntu/MyUbuntu(trusty,precise,lucid) The archive you
need is something like:
r-base_TheVersionIWant.orig.tar.gz
Extract it in a directory (maybe ~/R)
then (in the shell) enter the top directory of the unpacked archive
then you can read the INSTALL file, and run configure with the --enable-R-shlib option (otherwise you will not be able once compiled to run it in RStudio)
./configure --enable-R-shlib && make
then following the INSTALL file
make check
make pdf
make info
If all was ok, you can tell R studio where find the bin/R file it needs
export RSTUDIO_WHICH_R= myPahtTo/bin/R
and fire rstudio with
rstudio
You have an RStudio version running the desired R Version.
When you will close the terminal and the rstudio session you will come back to the system default version of R. Then repeat just the last two lines to come back when you want.
I am trying to do R CMD check before uploading my package to CRAN.
R CMD check --as-cran "my package folder".
However, it spits out this warning:
"checking for unstated dependencies in examples ... OK
WARNING
pdf is needed for checks on size reduction of PDFs"
I searched online but found no clue to solve this problem. This warning does not turn up when I run "R CMD check" only. And my package works with no problem. Could someone please tell me what might be wrong with my package?
qpdf is an external program necessary to reduce the size of pdf, it can be downloaded from the sourceforge site. You can install either the 32 bis or 64 bits version, both are working.
To install it, you download the file, and then copy the folder to your program folder.
Next you need to edit you system path to point to the bin folder by adding 'C:\Program Files\qpdf-version_numer\bin'. In a command batch (cmd) type qpdf to see if that has been set correctly, you should get the message
qpdf: an input file name is required
Usage: qpdf [options] infile outfile
For detailed help, run qpdf --help
Once this is done, the warning should be removed from your R CMD check
To add to Cedric's answer:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 7.0 is listed here).
Once you have extracted the zipped qpdf directory to your hard disk, perhaps under C:\Program Files, added C:\Program Files\qpdf-version_no\bin to your system PATH under the environment variables, and re-launched R so it picks up the new PATH, you need to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. Once you've done this, Windows will recognize the file as safe to run and allow other programs, including R, to use it.
I am developing a framework for reproducible computing with R. One problem that I am struggling with is that some R code might run perfectly in version X.Y-Z of a package, but then why you try to reproduce it 3 years later, the packages have updated, some functions are changed, and the code doesn't run anymore. This problem affects also for example Sweave documents that use packages.
The only way to confidently reproduce the results is by installing the R version and version of the packages that were used by the original author. If this was a single case, one could pull stuff from the CRAN archives and install appropriate versions. But for my framework this is impractical, and I need to have the package versions preinstalled.
Assume for now that I restrict myself to a single version of R, e.g. 2.14. What would be a practical way to install many versions of R packages, so that I can load them on the fly? I suppose I can do something like creating separate library directories for every version of every package and then using custom lib.loc arguments while loading them. This is going to be messy though. Any tips or previous attempts to do something similar?
My framework runs on Ubuntu server.
You could install packages with versions (e.g. rename to foo_1.0 directory instead of foo) and softlink the versions you want to re-create a given R + packages snapshot into one library. Obviously, the packages could actually live in a separate tree, so you could have library.projectX/foo -> library.all/foo/1.0.
The operating system gives you even more handles for complete separation, and the Debian / Ubuntu stack as a ton of those available. Two I have played with are
chroot environments: We use this to complete separate build environments from host machines. For example, all Debian uploads I produced are built in a i386 pbuilder chroot hosted on my amd64 Ubuntu server. Chroot is a very powerful Unix system call. Chroots, and particularly the pbuilder system built on top of it (for Debian package building) are meant to operate headless.
Virtual machines: This gives you full generality. My not-so-powerful box easily handles three virtual machines: Debian i386, Ubuntu i386 as well as Windoze XP. For this, I currently use KVM along with libvirt; this is Linux specific. I have also used VirtualBox and VMware in the past.
I would try to modify the DESCRIPTION file, and change the field "Package" there by adding the version number.
For example, you download the package source a from CRAN page (http://cran.r-project.org/web/packages/pls/). Unpack the compressed file (pls_2.3-0.zip) to a directory ("pls/"). The following steps are to change the package name in DESCRIPTION ("pls/DESCRIPTION") and installation with R command 'R CMD INSTALL pls/', where 'pls/' is a path to the package source with modified DESCRIPTION file.
Playing with R library paths seems a dangerous thing to me.