Utility for checking source file(s) for errors - r

When developing a package one can run R CMD check, which helpfully tells you any problems in your code (syntax errors, unstated dependencies, undefined variables).
Does a utility exist that will provide this functionality of R CMD check for individual source files?
I could create an empty package and move source files in their to check them, but that's both a pain, and overkill.

It sounds like you want to look at the codetools package.

Related

How to consider custom arguments of a package while building vignette?

I have a package which requires some custom arguments for installation. I can use R CMD INSTALL ---configure-args=... pkg.tar.gz to install the package successfully. I can also use R CMD check --install-args=configure-args=... to check the package after getting the custom arguments.
However, R CMD build doesn't have any arguments like --install-args and/or configure-args and R CMD build is used for building vignettes. I want to get the output of my R code chunks included in the vignette to its html output file and include it in the package source. Is there any way possible to build vignette with --configure-args or is there any workaround to produce the desired html vignette and include it in the package source?
Looking forward to your suggestions.
As you say, when R CMD build rebuilds your vignettes, it doesn't include a way to specify --include-args, so the temporary install needs to work with default settings.
There are two ways to achieve this. You could specify --no-build-vignettes. This would require that you have already put the built vignettes into the inst/doc directory, and R CMD build will just use what's there.
The other way is to make sure that on your machine the default configuration works. If you need to build on several different machines, this could be achieved by having your build script look at environment variables to find default settings if corresponding configure arguments aren't given. Then on each machine you specify the environment variables for R CMD build to see, e.g.
DEFAULT_LOCATION="/some/dir" R CMD build yourpackage

Questions about R package publishing and code visibility

When I use a package in R I install it and use it with loading it. Now what if I add a package which uses another package? Is this package automatically downloaded and loaded too? Or is it in general forbidden for a R package to use another package? I don't think that.
Suppose I want to publish a R package. Within my code, can I use functions from other packages and install and load these packages? Or how does this work when I need functions from other packages? Do I have to implement a message that this and that package is needed and that the user has to install and load it prior to it and I need to implement error catching functions in case the package cannot be found on the pc system?
When I want to publish a R package, can I use/call Java code within my package/code?
For a package which was already published - so let's take just as an example the fGarch package - I would like to see the complete code. How can I see this? I know that R is open source and I think it is more or less possible to just enter a function empty and get the code displayed, but sometimes this does not work and especially my question is: Is there a way I can look into the whole code of the package?
For a package which was already published, is it possible to see and look into all files which were submitted? So like a repository as git where all files are submitted - the code itself and further files which are needed like description files or whatever - and I can see these files and look into them?
Furthermore regarding this post here and hiding functions: Is there code in a R package which I cannot see as an end user? This refers also to my previous question, how can I or which way can I see the whole code in a R package?
I guess you have a few different questions here. Let's take them in the order you asked them:
What if I add a package which uses another package? Is this package automatically downloaded and loaded too? Or is it in general forbidden for a R package to use another package?
It is certainly not forbidden for an R package to use another R package. In fact, the majority of R packages rely on other packages.
The source code for each R package must include a text-based DESCRIPTION file in the root directory. In this file you will find (among other things) a "Depends" field, and an "Imports" field. Together, these two fields list all the other packages required to use this package. If a user doesn't already have these other packages installed in their local library, R will install them automatically when it installs the requested package.
If your package lists a dependency in "Depends", then the dependency package is attached whenever your package is attached. Thus if you looked at the source code for a package called "foo" and you see that its DESCRIPTION file contains the line
Depends: bar,
you know that when you call library(foo) in your R console, you have effectively done library(bar); library(foo)
This isn't always ideal. The package foo might only need a couple of functions from package bar, and bar might contain some other functions whose names could clash with other commonly used functions. Therefore, in general, if you are writing a package and you only want to use a few functions from another package, it would be better to use "Imports" rather than "Depends" to limit the number of unnecessary symbols being added to your user's search path.
Suppose I want to publish a R package. Within my code, can I use functions from other packages and install and load these packages
Yes, you can use functions from other packages. The simplest way to do this is to include the name of the package in the Depends field of your DESCRIPTION file.
However, when using just a few functions from another package inside your own package, best practice is to use the "Imports" field in the DESCRIPTION file, and use a namespace qualifier for the imported function in your actual R code. For example, if you wanted to use ggplot from the ggplot2 package, then inside your function you would call it ggplot2::ggplot rather than just ggplot.
If you publish your package for others to use, the dependencies will be installed automatically along with your package if the user calls install.packages with the default settings. For example, when I did:
install.packages("fGarch")
I got the associated message:
#> also installing the dependencies ‘timeSeries’, ‘fBasics’, ‘fastICA’
Do I have to implement a message that this and that package is needed and that the user has to install and load it prior to it and I need to implement error catching functions in case the package cannot be found on the pc system?
No, not in general. R will take care of this as long as you have listed the correct packages in your DESCRIPTION file.
When I want to publish a R package, can I use/call Java code within my package/code?
R does not have a native Java API, but you can use your own Java code via the rJava package, which you can list as a dependency for your package. However, there are some users who have difficulty getting Java to run, for example business and academic users who may use R but do not have Java installed and do not have admin rights to install it, so this is something to bear in mind when writing a package.
For a package which was already published - so let's take just as an example the fGarch package - I would like to see the complete code. How can I see this?
Every package available for download from CRAN has its source code available. In the case of fGarch, its CRAN page contains a link to the gzipped tarball of the source code. You can download this and use untar in R to review all the source code. Alternatively, many packages will have an easily-found repository on Github or other source-control sites where you can examine the source code via a browser. For example, you can browse the fGarch source on Github here.
For a package which was already published, is it possible to see and look into all files which were submitted? So like a repository as git where all files are submitted - the code itself and further files which are needed like description files or whatever - and I can see these files and look into them?
Yes, you can look at all the sources files for all the packages uploaded to CRAN on Github at the unofficial Github CRAN mirror here
Is there code in a R package which I cannot see as an end user? This refers also to my previous question, how can I or which way can I see the whole code in a R package?
As above, you can get the source code for any package via CRAN or Github. As you said, you can look at the source code for exported functions just by typing the name of that function into R. For unexported functions, you can do the same with a triple colon. For example, ggplot2:::adjust_breaks allows you to see the function body of the unexported function adjust_breaks from ggplot2. There are some complexities when an object-oriented system like S4, ggproto or R6 is used, or when the source code includes compiled C or C++ code, but I haven't come across a situation yet in which I was not able to find the relevant source code after a minute or two with an R console and a good search engine.

writing an R pkg that builds an executable during installation

I am writing an R package that needs to include an executable file (“mod.exe” in Windows environments or “mod” in Unix environments). One of the R functions in the package makes a call to the system that calls the executable as follows:
system(paste("mod", …))
Since CRAN will not accept packages with binary codeand because I would like the package to be portable to both Window and Unix systems, I would like to be able to just include the C source (“.h” and “.c”) files that can be used to build the executable “mod” in the source package. Ideally, when a user installs the R package, the source files should be compiled (with a C compiler available through Rtools on Windows or through a native C compiler on Unix) to create the executable “mod” during installation. Then, ideally, the executable “mod” would be stored in the binary package so that the aforementioned R function can call “mod” directly. (The .h and .c files have already been written so I do not want to rewrite or modify them.)
I've read http://r-pkgs.had.co.nz/package.html, looked through https://cran.r-project.org/doc/manuals/r-release/R-exts.html, and tried to find packages on CRAN that have already done something like what I’ve proposed, but haven’t been successful. I I attempted to solve my problem by putting all the C source files for “mod” into a /src directory in the source package along with a working makefile in the hope that this would cause the building of “mod” when the package was built and cause it to be stored somewhere in the binary package so that the R function could call “mod”. However, this did not work and when I try to look into the binary package the only thing I can see that was created is a /libs folder containing /i386 and /x64 folders, which both contain a dynamic linked library (on Windows, “RMCSim.dll”)-- I do not know what to do with this DLL.
If I create a version of the package in which the executable “mod” is placed into a package directory called “exec”, the R function can call the “mod” function. Unfortunately, this solution (1) is not portable to both Windows and Unix environments and (2) leads to a package that cannot be accepted by CRAN.
Please respond if you have any ideas for how to approach this problem or if you know of any examples of packages that do something similar with C source code. Thanks!

R -- What exactly does install_github do?

never used R before. I need to integrate R into continuous build.
The script I got has the line
RUN Rscript -e "devtools::install_github('my-repo', auth_token = '"$Github_Token"')"
I know this command will download the entire repo, but how is the package installed? Is it looking for the .R files, or is it looking for the .rba files?
My goal is to integrate a build process with a CI. I found a way to construct these rba files through a docker container, but these will not be checked into github. I need to make sure the install doesn't require these rba files, then I can move these files somewhere else.
The function install_github installs a package the same as any other method of package installation, but automates the download from github for you. The remote repository needs to be an R package, meaning it needs to have at least an R/ directory containing R code, a DESCRIPTION file containing the package metadata, and a NAMESPACE file describing the package imports and exports.
For install_github to work, it should not inherently require that your rba files are present.
For more information on packages, I suggest reading R packages.

Where to put package vignettes for CRAN submission?

From the Writing R Extensions Manual, I read that
As from R 2.14.0 the preferred location for the Sweave sources is the
subdirectory vignettes of the source packages, but for compatibility
with earlier versions of R, vignette sources will be looked for in
inst/doc if vignettes does not exist.
However, when I create a vignettes subdirectory of the package source, when I run devtools::check() or R CMD check I get a warning for Package vignette(s) without corresponding PDF. If I put the vignette (.Rnw and .pdf) in inst/doc the check completes without complaints. I tried looking in my library at installed packaged and did not see any directories named vignettes. Should I still use the deprecated location?
You put the .Rnw sources in vignettes/ as you did, but you missed out a critical step; don't check the source tree. The expected workflow is to build the source tarball and then check that tarball. Building the tarball will create the vignette PDF.
R CMD build ../foo/pkg
R CMD check ./pkg-0.4.tar.gz
for example will build a source package tarball from the sources in ../foo/pkg creating the .tar.gz package in the current directory with the package name and version appended. Then you run R CMD check on that source package.
If you want your vignette built for you put it in vignettes/ and build the source package. At some future date, R Core may remove the ability to build vignettes from inst/doc so go with the advised location now and avoid check the sources directly.
I had a hard time interpreting this too.
I believe the intention is that you should put the .Rnw file in vignettes/ and the PDF (suitably compacted) in inst/doc/, which technically agrees with the documentation if you read carefully enough. (That is, it says the sources should go in vignettes/. I don't see where it says in so many words that you ought to put the corresponding PDF in inst/doc/, but it doesn't not say it, and that interpretation seems to make R CMD check happy ...)
The resolution is in #GavinSimpson's answer (i.e. one is expected to build the tarball and then check it, rather than checking the source directory itself). (My two cents is that it might be best if R-core officially deprecated (and eventually removed) direct source checking rather than confusing all of us groundlings ...)

Resources