R: Adding configuration options on package install - r

I am developing a simple R package in which I would like to specify some local configuration options on package install. In particular, I would like the user to input a location on their computer on which to store package output data.
The package is most basically a random number generator. When used, it will generate a new random number, check the user-specified data file to make sure that number has not been generated, then either generate a new number, or append the new number to the data file.
I believe I could come up with a way to do this, but I'm wondering if there is a formal way of specifying something like configuration options that are particular to the local installation.
I've scoured the internet for information about this but not found much. This page may be somewhat related but in the end I didn't think this was exactly what I would want.
Thank you for any advice you can give!

Related

R - Bibliometrix - Biblioshiny: See R code generated by Biblioshiny

I am using Biblioshiny for Bibliometric analysis. As I am quite new to R, and would like to learn more about the underlaying code used by biblioshiny; I was wondering if it is possible to see the resulting R-code generated through the options configured in the web interface in biblishiny. E.g. when creating a ci-citation network in Biblioshiny, can I see the actual executed R-code used to generate this network?
Recently. I though perhaps one can enable a debug-mode and/or see the code through some logs. I do not know if this is the case, or if better solutions exists.

Using built-in data in an R package [duplicate]

This is likely an easy answer that's been answered numerous times. I just lack the terminology to search for the answer.
I'm creating a package. When the package loads I want to have instant access to the data sets.
So lets say DICTIONARY is a data set.
I want to be able to do DICTIONARY rather than data(DICTIONARY) to get it to load. How do I go about doing this?
From R-exts.pdf (online source):
The ‘data’ subdirectory is for data files, either to be made available
via lazy-loading or for loading using data(). (The choice is made by
the ‘LazyData’ field in the ‘DESCRIPTION’ file: the default is not to
do so.)
Adding the following to the DESCRIPTION file should do it:
LazyData: true

R package dev: should I make data files internal or external?

(Trying again with this question to make it more clear.)
I am attempting to write a package that makes it easier to access data from a web API, and deciding whether to make lookup tables and query defaults internal or external data, as outlined in the Data chapter of R Packages.
As I understand, there are drawbacks to each. Internal data is meant for data only used by the package, invisible to users. It is added to the package with devtools::use_data(x, mtcars, internal = TRUE) which adds sysdata.rda to the R/ package folder. However, although the package "needs" the data tables, I also want my data to be visible to the users, so they can correct errors, and perhaps add additional data files by pull request to extend the capability of the package. Furthermore, since I'm dealing with multiple files, not all available at the moment, rebundling everything into R/sysdata.rda every time there's a change seems inconvenient.
An alternative would be to make the lookup tables and query defaults external data, which is added with the default internal = FALSE flag: devtools::use_data(x, mtcars), adding mtcars.rda to the data/ package folder. The advantage is that such data is clearly visible to the user, but the downside is that I don't know how to access it from within the package functions without getting an error when running devtools::check(): object 'querydefaults' not found. What is the proper way to do this?
You can add the dataset both as external and internal, and it resolves the issue with devtools::check(). See the RIC package as an example.

How to automatically load data in an R package?

This is likely an easy answer that's been answered numerous times. I just lack the terminology to search for the answer.
I'm creating a package. When the package loads I want to have instant access to the data sets.
So lets say DICTIONARY is a data set.
I want to be able to do DICTIONARY rather than data(DICTIONARY) to get it to load. How do I go about doing this?
From R-exts.pdf (online source):
The ‘data’ subdirectory is for data files, either to be made available
via lazy-loading or for loading using data(). (The choice is made by
the ‘LazyData’ field in the ‘DESCRIPTION’ file: the default is not to
do so.)
Adding the following to the DESCRIPTION file should do it:
LazyData: true

Where in R do I permanently store my custom functions?

I have several custom functions that I use frequently in R. Rather than souce this file (or parts thereof) in each script, is there some way to add this to a base R file such that they are always available when I use R?
Yes, create a package. There are numerous tutorials as well as the Writing R Extensions manual that came with your copy of R.
It may seem like too much work at first, but you will probably be glad that you did this in the longer run.
PS And you can then load that package from ~/.Rprofile. For really short code, you can also define it there.
A package may be overkill for a for a few useful functions. I'd argue there's nothing wrong with explicitly source()ing them as you need them - at least it is explicit so that if you email someone your code, you won't forget to include those other scripts.
Another option is to use the .Rprofile file. You can read about the details in ?Startup. Basically, the idea is that:
...a file called ‘.Rprofile’ is searched for in the current directory or
in the user's home directory (in that order). The user profile file is
sourced into the workspace.
You can read here about how many people use this functionality.
The accepted answer is best long-term: Make a package.
Luckily, the learning curve for doing this has been dramatically reduced by the devtools package: It automates package creation (a nice assist in getting off on the right foot), encourages good practices (like documenting with roxygen2, and helps with using online version control (bitbucket, github or other), sharing your package with others. It's also very helpful for smoothing your way to CRAN submission.
Good docs at http://adv-r.had.co.nz and http://r-pkgs.had.co.nz .
to create your package, for instance you can:
install.packages("devtools")
devtools::create("path/to/package/pkgname")
You could also look at the 'mvbutils' package: it lets you set up a hierarchical set of "tasks" (folders with workspace ".RData" files in them) such that you can always see what's in the ancestral tasks (ie the ancestors are in the search() path). So you can put your custom functions in the "starting task" where you always start R; and then you change to vwhatever project-specific task you require, so you can avoid cluttered workspaces, but you'll still be able to use (and edit) your custom functions because the starting task is always ancestral. Objects (including functions) get stored in ".RData" files and are thus loaded/saved automatically, but there are separate text-backup facilities for functions.
There are lots of different ways of working in R, and no "one-size-fits-all" best solution. It's also not easy to find an overview! Speaking just for myself:
I'm not a fan of having to 'source' everything in every time; for one thing, it simply doesn't work with big data sets and/or results of model runs.
I think packages are hard to create and maintain; there is a really significant overhead. After the first 5 packages you write, it does get a bit easier provided you do it on at least a weekly basis so you don't forget how, but really...
In fact, 'mvbutils' also has a bunch of tools for facilitating the creation and (especially) maintenance of packages, designed to interface smoothly with the task-hierarchy system. I use & edit my own packages all the time (including editing mvbutils itself); but if it wasn't for the tools in 'mvbutils', I'd be grinding my teeth in frustration most days of the week.

Resources