Skip to content

[R-pkg-devel] Proper way to ask a user to set permanent variables?

8 messages · Jonathan Greenberg, Duncan Murdoch, Gábor Csárdi +3 more

#
Folks:

My package gdalUtils is a wrapper for a set of binaries on disk (the GDAL Utilities) -- these have about as many places to install as there are people installing it, and the system environment variables aren't always much help (they aren't always set) for locating them.  My package is trying to dummy-proof the usage as much as possible, so one of the things it does is if it can't find the install, it goes search for the install in, first, standard locations and runs a short test to see if the install is valid and, if not, goes on a longer hunt.  Right now, it does this search everytime someone boots up R and uses it, which slows down the process.

What I'm wondering is twofold:

1) Are there any packages/methods by which user "preferences" are saved that don't require saving workspaces (e.g. does R have a standardized "preferences" location that packages can use).

2) If the answer to #1 is "no", what is the preferred method for saving variables for use by packages that are always restored on boot -- e.g. I was thinking something like .Renviron but I think that's Rstudio only.  I'm concerned with workspace-type saves since I feel like that often results in a ton of variables being saved.

Thanks!

--j
#
On 14/01/2020 11:06 a.m., Jonathan Greenberg wrote:
You can read ?Startup to see what happens when R starts up.  Putting 
environment variables in .Renviron would work; so would putting R code 
in .Rprofile.  However, those files both belong to the user, so your 
package shouldn't write to them without asking, and it's probably better 
not to write there at all.

A few packages put cached information into a ~/.R directory; I'd suggest 
putting your stuff into ~/.R/gdaUtils/* (after asking for permission).

Duncan Murdoch
#
You can use the rappdirs package to look up the standard places for
permanent config, cache etc. files. E.g. on macOS:

? rappdirs::user_cache_dir()
[1] "/Users/gaborcsardi/Library/Caches"

Gabor
On Tue, Jan 14, 2020 at 4:10 PM Jonathan Greenberg <jgreenberg at unr.edu> wrote:
#
I second that - it provides the most consistent way of storing information permanently.

I was in a similar situation, and ended up using the function at 

https://github.com/Exp-Micro-Ecol-Hub/dmdScheme/blob/master/R/cache.R <https://github.com/Exp-Micro-Ecol-Hub/dmdScheme/blob/master/R/cache.R>

And the location `rappdirs::user_config_dir(appname = "dmdScheme", appauthor = "dmdScheme?)` as the permanent cache.

I either either 
- use a temporary cache if the cache does not exist
- if the cache does exist, use that one, and
- use the `createPermanent` argument to create the cache so that it can be used.

Cheers,

Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Orcid ID: 0000-0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Z?rich
Office Y34-J-74
Winterthurerstrasse 190
8075 Z?rich
Switzerland

Office:	+41 (0)44 635 47 64
Cell:       	+41 (0)78 630 66 57
email:      Rainer.Krug at uzh.ch
		Rainer at krugs.de
Skype:     RMkrug

PGP: 0x0F52F982
#
Jonathan,

In all but one (maybe two?) of my packages I found relying on options()
sufficient. I usually follow the somewhat-common pattern of creating a
package-local environment in R/init.R or R/zzz.R. I then fill it with values
reflecting options() (often under a tag starting with the package name)
and/or environment variables, and sometime also provide 'setters' to update
the environment values. That have proven to be both good enough and rather
robust and, as an added benefit, does not depend on anything further.

Cheers, Dirk
1 day later
#
Hi Dirk,

The package-local environment is definitely a good approach (I use it myself an a few packages). And the options() are nice as they represent a standardised interface in R (Note to myself: I should use these more in my packages).

But unless I am missing something, these are not persistent between sessions? I assume, that is not an issue in your case?

Cheers,

Rainer
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Orcid ID: 0000-0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Z?rich
Office Y34-J-74
Winterthurerstrasse 190
8075 Z?rich
Switzerland

Office:	+41 (0)44 635 47 64
Cell:       	+41 (0)78 630 66 57
email:      Rainer.Krug at uzh.ch
		Rainer at krugs.de
Skype:     RMkrug

PGP: 0x0F52F982
#
Options are not persistent between sessions unless the user wants them to
be. You can have users set the options in their .Rprofile either in the
working directory of the project or their home directory. This is the
method that the {usethis} package has for storing default names. The only
downside to this is that any R scripts associated will not be reproducible
unless paired with the .Rprofile file.

Best,
Zhian
On Fri, Jan 17, 2020 at 8:01 AM Rainer M Krug <Rainer at krugs.de> wrote:

            

  
  
#
On 17 January 2020 at 09:49, Zhian Kamvar wrote:
| Options are not persistent between sessions unless the user wants them to
| be. You can have users set the options in their .Rprofile either in the
| working directory of the project or their home directory. This is the

Yes, precisely.

| method that the {usethis} package has for storing default names. The only

Sure, but the point of the approach is that it needs no other packages.

One may of course use a helper function or tool to edit / add / modify but
key is that every standard editor used to modify R code can modify .Rprofile.

| downside to this is that any R scripts associated will not be reproducible
| unless paired with the .Rprofile file.

Sure but it shares that problem with _every_ machine-local configuration method.
It really is a different problem, and again one you _could_ address in
initialization code by checking for options being present, their values etc pp

Dirk