I have just created a Rpackage in RStudio, built it and installed into the same R version. Basically I have pressed the "Build and reload the package (Ctrl + Shift + B)" button. By this method I get the package installed in the same R version, so that library(mypackage) works directly and I can use my own package in another RSession.
However, I would like to pass the package for others to be used and test that all package dependencies work as desired. Therefore, I have invoked "Build binary package" in order to have package mypackage_{version_number}.zip.
What is the preferred way to test the installing of a newly created binary package and, especially, its dependencies?
My primary environment has all dependencies installed, therefore, Imports: clausus in DEPENDENCIES file seem to have no effect. The installing of all necessary dependencies is exactly what I would like to test.
I found the idea of trying to install the package into another R version. However, in that case I could test the dependencies only once, because all the dependencies (hopefully) get installed to that R version when installing the package and its dependencies first time.
If Travis is not an option, you could test your package using win builder (http://win-builder.r-project.org/) through devtools::build_win().
Make sure to add the maintainer role in authors in the DESCRIPTION of your package, because win builder will send an email once the tests are completed.
Related
I'm developing an R package in Github (ConceptionTools) that depends on another R package (CreateFlowChart), also in Github. I have followed the instructions for defining remote dependencies. My DESCRIPTION file includes:
Imports: CreateFlowChart
Remotes: github::IMI-ConcePTION/CreateFlowChart
However, when I install my package, with the command:
devtools::install_github("IMI-ConcePTION/ConceptionTools")
This dependency is not installed. I simply get "skipping 1 packages not available: CreateFlowChart". It doesn't appear to be trying to use the Remote, since there is no error related to Github.
When I install the dependency directly, that works:
devtools::install_github("IMI-ConcePTION/CreateFlowChart")
Does anybody have any idea of what could be going on here? I'm racking my brain, as it seems to be a quite straightforward case of what the documentation shows. I'm using R 4.0.3 (on Windows 10) and devtools 2.3.2.
There was a typo in the name of the dependency package in its DESCRIPTION file.
This does not make the package fail when installing it directly, but it leads devtools not to find it as a dependency.
The latest version of a package that my package Imports introduced a breaking change (I think it may be a bug and have filed an issue about it). When I specify the specific version of the package needed in my package's DESCRIPTION file, i.e.:
Imports:
packageName (== 0.1)
Then the package builds locally fine and passes all tests. However, the package does not pass the Travis-CI build; the following error is returned:
Package required and available but unsuitable version(packageName)
Does this error suggest that the package will not pass CRAN's checks? How can I address it? The source for the package is here.
Suppose I have an R package on GitHub. Is there any way, I can have an RStudio user of my package avoid first running:
install.packages("devtools")
library(devtools)
and just directly use:
install_github("My-Github-username/My-package-name")
library(My-package-name)
Can I for example make any changes to my R package such that my package automatically does install.packages("devtools") and library(devtools) for the user?
You somehow need to get your user to install and build the package locally to use it. The package can't install itself. Think of the package as a collection of code. You somehow need to get the code from GitHub to your user's computer.
If using devtools is not an option, you could have them do this manually (by, say, downloading the .tar.gz from GitHub) and then build the package themselves, using R CMD build and R CMD install such. There are some nice explanations out there on how to go about doing this. Using devtools::install_github() is a convenient, easy function that takes care of all of those steps for you.
(The exception to my statement "The package can't install itself" is that you can use devtools to install devtools.)
I'm running R CMD INSTALL --build package on a windows computer. My package imports a couple of other packages which themselves depend on some more packages. I have all dependencies installed in the local r_libs folder and everything works.
Now sometimes I have the my package source code on a different windows computer. On this computer I don't have all the dependency packages installed.
When I try to use R CMD INSTALL --build package, I get the obvious "ERROR: dependencies 'package a', 'package b', etc, are not available for package".
My question is: Can I build the package using R CMD INSTALL --build without the dependency checks and without removing the Import and Depends entries in the DESCRIPTION file?
After consulting --help, I tried the --no-test-load option but no luck.
I reckon you want to build a .zip binary version of the package on a computer where not all dependencies are installed. And I'm afraid I'll have to disappoint you, as this won't be possible.
Building a binary package is done in two steps: first the package is installed from source (that's why you have to use R CMD INSTALL and then the created binaries are zipped in a convenient format for installation on a windows machine. The dependencies are checked at time of installation from source, and any missing dependencies will throw the error you're facing.
As R needs information from the dependencies at time of installation from source, you can't get around installing them before building the whole thing. This also makes sense. An installed package in R contains a set of .rds files which contain package information in a more convenient format for R. In order to create that information for the NAMESPACE file, it needs to be able to access the packages from which functions are imported. If not, it can't construct the correct information about the namespace.
So your only option is to install the dependencies on the computer you use to build. And if you actually want to use the package on that computer, you'll have to install those dependencies anyway.
More information:
R Internals : https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Package-Structure
Writing R Extensions: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-namespaces
I am developing an R package for which I wrote some test files using R package testthatand placed the files under tests folder. I ran R CMD build on a Linux machine with R version 3.0.0. The command failed because testthat package requires R version at least 3.1.0.
Two following things I can do, but I am not sure which is better.
I can remove whole things in tests folder, so that my R package will also work for R version less than 3.1.0. As I notice, test files are not required for building an R package. Those are only useful for the developer.
I can keep all test files, but explicitly mention Depends: R (>= 3.1.0) in the DESCRIPTION file. The downside is that: (1) the package will be available to less users; and (2) more important, it depends on testthat package. Whatever updates there might affect my package potentially.
Which one do you think is better?
[update]
I followed the suggestion from # hrbrmstr, which is, I first built the package using R 3.1.0, and then check it on a Linux machine with R 3.0.0. But I still failed. The log is as follows.
* checking package namespace information ... OK
* checking package dependencies ... ERROR
Package suggested but not available: ‘testthat’
The suggested packages are required for a complete check.
Checking can be attempted without them by setting the environment
variable _R_CHECK_FORCE_SUGGESTS_ to a false value.
Any ideas to fix this issue?Or should I take approach 1 or 2 as stated above?