[Bioc-devel] BiocFileCache for developers

[Martin Morgan]

On 12/01/2017 11:23 AM, Sean Davis wrote:
> On Fri, Dec 1, 2017 at 11:16 AM, Shepherd, Lori <
> Lori.Shepherd at roswellpark.org> wrote:
> 
>> So having a user argument might be best.  Or defining a unique cache
>> location for your package would be another option.
>>
> 
> The R package development policies actually has a statement that may be
> helpful in thinking about this. Your mileage may vary in the
> interpretation....
> 
> 
>>     - - 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.
>>
>>

Actually, CRAN policies.

The CRAN policy is definitely appropriate for vignette and example code, 
and certainly functions by default should not write to locations where 
they will potentially overwrite existing resources. The policy makes it 
impossible to write files that persist across sessions, which is the 
objective for BiocFileCache.

For the original question, I think there's often a case for 
user_cache_dir(appname="mikes-package-name")

Martin

> https://cran.r-project.org/web/packages/policies.html
> 
> Sean
> 
> 
> 
>>
>> Lori Shepherd
>>
>> Bioconductor Core Team
>>
>> Roswell Park Cancer Institute
>>
>> Department of Biostatistics & Bioinformatics
>>
>> Elm & Carlton Streets
>>
>> Buffalo, New York 14263
>> ------------------------------
>> *From:* Bioc-devel <bioc-devel-bounces at r-project.org> on behalf of Sean
>> Davis <seandavi at gmail.com>
>> *Sent:* Friday, December 1, 2017 11:06:39 AM
>> *To:* Michael Love
>> *Cc:* bioc-devel at r-project.org
>> *Subject:* Re: [Bioc-devel] BiocFileCache for developers
>>
>> On Fri, Dec 1, 2017 at 10:28 AM, Michael Love <michaelisaiahlove at gmail.com
>>>
>> wrote:
>>
>>> hi,
>>>
>>> I'm writing a function which currently uses BiocFileCache to store a
>>> small data.frame and one or more TxDb objects, so that these objects
>>> are persistent and available across sessions (or possible available to
>>> multiple users).
>>>
>>> In the simplest case, I would call
>>>
>>> bfc <- BiocFileCache()
>>>
>>> inside my function, which will check the default location:
>>>
>>> user_cache_dir(appname = "BiocFileCache")
>>>
>>> In general, should developers also support the user specifying a
>>> specific location for the BiocFileCache? So functions using
>>> BiocFileCache should have an argument that overrides the above
>>> location?
>>>
>>
>> On some systems, the user home directory is not large (such as on HPC
>> systems) or has strong quotas. The default user_cache_dir may not be the
>> best choice there.
>>
>> Sean
>>
>>
>>>
>>> thanks,
>>> Mike
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>>
>>
>> --
>> Sean Davis, MD, PhD
>> Center for Cancer Research
>> National Cancer Institute
>> National Institutes of Health
>> Bethesda, MD 20892
>> https://seandavi.github.io/
>> https://twitter.com/seandavis12
>>
>>          [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> Bioc-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>> This email message may contain legally privileged and/or confidential
>> information. If you are not the intended recipient(s), or the employee or
>> agent responsible for the delivery of this message to the intended
>> recipient(s), you are hereby notified that any disclosure, copying,
>> distribution, or use of this email message is prohibited. If you have
>> received this message in error, please notify the sender immediately by
>> e-mail and delete this email message from your computer. Thank you.
>>
> 
> 
> 


This email message may contain legally privileged and/or...{{dropped:2}}