Skip to content

Correct use of tools::R_user_dir() in packages?

6 messages · Dirk Eddelbuettel, Simon Urbanek, Iñaki Ucar +1 more

Original
Carl Boettiger
# 
tools::R_user_dir() provides configurable directories for R packages
to write persistent information consistent with standard best
practices relative to each supported operating systems for
applications to store data, config, and cache information
respectively.  These standard best practices include writing to
directories in the users home filespace, which is also specifically
against CRAN policy.

These defaults can be overridden by setting the environmental
variables R_USER_DATA_DIR , R_USER_CONFIG_DIR, R_USER_CACHE_DIR,
respectively.

If R developers should be using the locations provided by
tools::R_user_dir() in packages, why does CRAN's check procedure not
set these three environmental variables to CRAN compliant location by
default (e.g. tempdir())?

In order to comply with CRAN policy, a package developer can obviously
set these environmental variables themselves within the call for every
example, every unit test, and every vignette.  Is this the recommended
approach or is there a better technique?

Thanks for any clarification!

Regards,

Carl

---
Carl Boettiger
http://carlboettiger.info/
Dirk Eddelbuettel
#
On 27 June 2023 at 15:36, Carl Boettiger wrote:
| tools::R_user_dir() provides configurable directories for R packages
| to write persistent information consistent with standard best
| practices relative to each supported operating systems for
| applications to store data, config, and cache information
| respectively.  These standard best practices include writing to
| directories in the users home filespace, which is also specifically
| against CRAN policy.
| 
| These defaults can be overridden by setting the environmental
| variables R_USER_DATA_DIR , R_USER_CONFIG_DIR, R_USER_CACHE_DIR,
| respectively.
| 
| If R developers should be using the locations provided by
| tools::R_user_dir() in packages, why does CRAN's check procedure not
| set these three environmental variables to CRAN compliant location by
| default (e.g. tempdir())?
| 
| In order to comply with CRAN policy, a package developer can obviously
| set these environmental variables themselves within the call for every
| example, every unit test, and every vignette.  Is this the recommended
| approach or is there a better technique?

My use evolved to something like this (from in this case r2u, but similar in
a few other packages)

    .defaultConfigFile <- function() {
        pkgdir <- tools::R_user_dir(packageName())      # ~/.local/share/R/ + package
        if (dir.exists(pkgdir)) {
            fname <- file.path(pkgdir, "config.dcf")
            if (file.exists(fname)) {
                return(fname)
            }
        }
        return("")
    }

You can then create config reader and writers functions that have a file
argument (set to the above) whicg you can override in tests with tempfile()
allowing you to write and then read.

Given the 'thou shalt not write to $HOME' rule, I often have parameter
getters with default values which, if a config file is found (with the name
per the helper above), also read it and use it to override the defaults.
Works for me, and is lightweight via a 'using batteries included'
zero-depends approach.

Dirk
Simon Urbanek
# 
Carl,

I think your statement is false, the whole point of R_user_dir() is for packages to have a well-defined location that is allowed - from CRAN policy:

"For R version 4.0 or later (hence a version dependency is required or only conditional use is possible), packages may store user-specific data, configuration and cache files in their respective user directories obtained from tools::R_user_dir(), provided that by default sizes are kept as small as possible and the contents are actively managed (including removing outdated material)."

Cheers,
Simon
Carl Boettiger
# 
Thanks Simon, I was very much hoping that would be the case!  It may
be that I just need to put the version requirement on 4.0 then.  I
will be sure to add this version restriction to my packages (which
technically I should be doing anyway since this function didn't exist
in early versions of `tools`.)

Cheers,

Carl

---
Carl Boettiger
http://carlboettiger.info/

On Wed, Jun 28, 2023 at 12:59?PM Simon Urbanek
<simon.urbanek at r-project.org> wrote:
Iñaki Ucar
#
On Thu, 29 Jun 2023 at 01:34, Carl Boettiger <cboettig at gmail.com> wrote:
In my experience, you *can* store stuff in those directories, but you
are required to clean up after yourself in CRAN checks. In other
words, if something is left behind when the check ends, CRAN won't be
happy.

I?aki

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Carl Boettiger
    

    

      
      #
    

  


  

      
Thanks I?aki, that has been my experience as well.  But that is also
not how I read the current policy that Simon said.  First, my
understanding of the current policy is that in general, 'cleaning up'
is not consistent with the policy of not writing to home, hence my
suggestion of overriding the default locations by setting the env vars
R_USER_DATA_DIR etc to tmpdir() in testing mode.  Of course this could
be done globally on the CRAN testing machines, but I gather that is
not the case.   Second, having re-read the policy, it does seem to say
quite clearly that using R_user_dir() is an exception to the 'thou
shalt never write to $HOME' rule (provided you restrict to version

            

      
      
      
    

        
CRAN packages which tools::R_user_dir(), I would venture to say that
this policy and how it relates to the $HOME rule for
tests/examples/vignettes is maybe not as clear as it might be.
Unfortunately this rule does not seem to be covered by explicit code
in the `R CMD check` routine, so we cannot consult the source code to
get a more definitive answer about questions like whether clean-up or
use of temp files is or is not required by policy, though maybe this
is mostly my own confusion.  The examples in this thread have
definitely been helpful to me in understanding how others handle
persistent data/config/cache mechanisms.

Regards,

Carl


---
Carl Boettiger
http://carlboettiger.info/

        
On Thu, Jun 29, 2023 at 1:17?AM I?aki Ucar <iucar at fedoraproject.org> wrote: