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 >=4.0). In my experience of both my own packages and what I see among 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 <iu...@fedoraproject.org> wrote: > > On Thu, 29 Jun 2023 at 01:34, Carl Boettiger <cboet...@gmail.com> wrote: > > > > 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`.) > > 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 > > > > > Cheers, > > > > Carl > > > > --- > > Carl Boettiger > > http://carlboettiger.info/ > > > > On Wed, Jun 28, 2023 at 12:59 PM Simon Urbanek > > <simon.urba...@r-project.org> wrote: > > > > > > 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 > > > > > > > > > > On 28/06/2023, at 10:36 AM, Carl Boettiger <cboet...@gmail.com> 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? > > > > > > > > Thanks for any clarification! > > > > > > > > Regards, > > > > > > > > Carl > > > > > > > > --- > > > > Carl Boettiger > > > > http://carlboettiger.info/ > > > > > > > > ______________________________________________ > > > > R-devel@r-project.org mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > > > > > > > ______________________________________________ > > R-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Iñaki Úcar ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
