Re: [R-pkg-devel] saving user preferences per workspace
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 :
> 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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Run-away R CMD check ?
On 12 December 2015 at 12:10, Dirk Eddelbuettel wrote: | | On 12 December 2015 at 18:57, Uwe Ligges wrote: | | CRAN has different approaches. | | | | Under Windows, I typically have an R process that controls the check | | process and writes out the process id and timestamp and then starts R | | CMD check. Another watcher simply kills the process of a given process | | ID including all childs if they are beyond some timeout threshold. | | I was leaning towards something like that. We'll see what I end up doing... I am also going to keep closer tabs on how long each test takes -- some packages are clearly more expensive than others. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] saving user preferences per workspace
Maybe you'll also find the 'rappdirs' package useful.
Gabor
On Sun, Dec 13, 2015 at 8:34 AM, Peter Meissner
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 :
>
>> 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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
