[R-pkg-devel] saving user preferences per workspace

Henrik Bengtsson henrik.bengtsson at gmail.com
Sat Dec 19 17:22:01 CET 2015


The CRAN Policies [https://cran.r-project.org/web/packages/policies.html] say:

"- Packages should not write in the users’ home filespace, nor
anywhere else on the file system apart from the R session’s temporary
directory (or during installation in the location pointed to by
TMPDIR: and such usage should be cleaned up). Installing into the
system’s R installation (e.g., scripts to its bin directory) is not
allowed.

Limited exceptions may be allowed in interactive sessions if the
package obtains confirmation from the user."

CRAN package R.cache saves to file after getting user's approval.
First time the package is loaded it asks the user for permission to
create "root" directory to store cached data.   If the directory
already exists, then it won't ask (again).  If it does not exist and
user disapproves to create it or R is running in an interactive, then
it falls back to using a temporary directory (which is still useful
for caching/memoization).

/Henrik
(author of R.cache)

On Sun, Dec 13, 2015 at 12:34 AM, Peter Meissner
<retep.meissner at gmail.com> wrote:
> Hey,
>
> as far as I understand it, it is not ok to do any writing to the filesystem
> (except tempfiles) behind the back of the user - never ever (except on
> installation).
>
> But what you can do is implement explicit functions to explicitly save and
> load options.
>
> Furthermore, you can tell the user, that the load function will always look
> for:
>
> 1. brailer_options_file.opt in the current working directory
> 2. for an brailer_options_file entry in the .Renviron file to determine if
> there might be a file to load options from (e.g. brailer_options_file
> entry=~/brailer_options_file.opt)
> 3. else the function does not laod any options
>
> Depending on what is appropriate for your package you might than run the
> options load function on package startup via putting an .onLoad function
> into your R/zzz.R file.
>
> I am not sure if that's the most elegant or efficient way to implement such
> a thing but it served me well for the wikipediatrend package where I needed
> a way for caching downloads and I am convinced that it is CRAN policies
> compliant.
>
> If there are better ideas or room for discussion I am eager to here it.
>
>
> Best, Peter
>
> 2015-12-12 21:52 GMT+01:00 Godfrey, Jonathan <A.J.Godfrey at massey.ac.nz>:
>
>> Hello,
>>
>> I wish to offer users of my BrailleR package the ability to save their
>> preferences, which may change by the workspace.
>>
>> I've toyed with the ideas:
>>
>> 1.        saving a file in the corresponding folder;  or,
>>
>> 2.       creating an object containing all the settings in the workspace
>>
>>
>> In either scenario, the settings get picked up next time the user loads
>> the package in the right workspace. Both have worked.
>>
>> My problem is that I think my functions to create or modify the file or
>> object breach CRAN policies. I am certainly getting a NOTE for using
>> assign(..., pos=1)
>>
>> I had thought to try using the parent environment instead of explicitly
>> using 'pos=1' but sometimes my functions are operating at the grandchild
>> level with respect to pos=1 and therefore fail.
>>
>> I think my previous solution of writing a file in the current folder was
>> only getting past the CRAN checks because I was doing it with a condition
>> of running R in interactive mode. if(interactive()){...}
>> But I think it is a breach of the policies to write a file to the user's
>> hard drive, and sneaking around with a solution that CRAN checks can't cope
>> with (yet) really doesn't work for me.
>>
>> Any ideas, especially pointers to other packages that do manage this task
>> would help me greatly.
>>
>> Thanks for any help/advice,
>> Jonathan
>>
>>
>>
>>         [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
>         [[alternative HTML version deleted]]
>
> ______________________________________________
> R-package-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list