[R-pkg-devel] Dealing with not so temporary files

Joris Meys Joris.Meys at ugent.be
Thu Mar 15 11:23:56 CET 2018


Hi Gabor,

That's indeed the case, but I see good reasons for the CRAN policy when we
take reproducability into account. Afaik, CRAN and R always strived to
provide tools that give the same output regardless of the machine they're
running on when opened in a fresh R session. If packages store settings on
disk without explicitly asking the user, you increase the risk of code
generating different results on different machines without the user
necessarily be aware of it, or why it happens.

Obviously there's much to say in favor of allowing packages to store
settings, but there's a trade off between user experience and
reproducability that needs to be taken into account imho.

Cheers
Joris

On Thu, Mar 15, 2018 at 11:14 AM, Gábor Csárdi <csardi.gabor at gmail.com>
wrote:

> This seems to be a good occasion to note that the CRAN policy does not
> seem to conform
> the industry standards. Applications can actually store user level
> configuration information,
> cached data, logs, etc. in the user's home directory, and there
> standard way to do this.
>
> Here is the Apple recommendation:
> https://developer.apple.com/library/content/documentation/
> FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/
> FileSystemOverview.html#//apple_ref/doc/uid/TP40010672-CH2-SW1
>
> AFAIK all modern Linux distributions use the XDG standard, or
> something close to it:
> https://specifications.freedesktop.org/basedir-spec/
> basedir-spec-latest.html
>
> On Windows there are APIs to retrieve the right locations, but
> generally it is all in
> `%APPDATA%`: https://msdn.microsoft.com/en-us/library/dd378457(v=vs.85).
> aspx
>
> The rappdirs package helps you to select the right location, in a
> platform independent way.
> Of course according to the CRAN policy, you still need to ask the user
> interactively
> before writing to the directories that rappdirs returns.
>
> I think a good practice is to use "R" as the application name, and
> within that a subdirectory
> that is the package name. This is a way to do it, for configuration files:
>
> ## Windows
> ❯ rappdirs::user_config_dir("R", version = "mypackage")
> [1] "C:/Users/gaborcsardi/AppData/R/R/mypackage"
>
> ## macOS
> ❯ rappdirs::user_config_dir("R", version = "mypackage")
> [1] "/Users/gaborcsardi/Library/Application Support/R/mypackage"
>
> ## Linux
> ❯ rappdirs::user_config_dir("R", version = "mypackage", os = "unix")
> [1] "/Users/gaborcsardi/.config/R/mypackage"
>
> Gabor
>
> On Tue, Mar 13, 2018 at 8:52 AM, Joris Meys <Joris.Meys at ugent.be> wrote:
> > Duncan gave one option. The other option is to provide a specific
> > write2disk() function or so that allows the user to determine whether
> > he/she wants to save the data. Then the user can decide exactly where he
> > wants to find it.
> >
> > The other important part is the format in which it's saved. Users can
> > simply use save() or write.csv() (or any of the readr functions if you
> > must) to store whatever data they want in the format they want. There's a
> > lot of database connections possible as well if that's needed. The only
> > reason I see to provide a specific write function or argument, is when
> the
> > storage is done in a nonstandard format. And then it makes sense to
> provide
> > both read_myformat() and write_myformat() in some form. That's what I as
> an
> > R user would expect.
> >
> > Fwiw: I have seen the commotion on that discussion recently as well, but
> > this is really nothing new. For as long as I remember, writing to disk
> only
> > happens when you use a function that does explicitly that. Which makes
> > sense as well, as eg my students often run R in a shared environment
> during
> > classes, and sysadmins don't like software that starts writing files
> > everywhere.
> >
> > Cheers
> > Joris
> >
> >
> >
> > On Tue, Mar 13, 2018 at 12:32 AM, Duncan Murdoch <
> murdoch.duncan at gmail.com>
> > wrote:
> >
> >> On 12/03/2018 6:26 PM, Roy Mendelssohn - NOAA Federal wrote:
> >>
> >>> Hi All:
> >>>
> >>> Recently there was a proper admonishment to a developer that it is bad
> >>> etiquette writing to a user's home directory,  and for temporary files
> use
> >>> the functions tempdir() and tempfile().  I am working on a new package
> >>> (presently on Github) that downloads data from a remote server,  reads
> the
> >>> data into R,  but I would like to save that file for the user to access
> >>> later if they so desire.  Saving to the "temp directory" is not a good
> >>> option for that,  want to put it somewhere where the user can easily
> find
> >>> it.  What is the proper etiquette for this?  Even if I provide an
> argument
> >>> for the user to specify the location to save the file,  I should
> provide a
> >>> default location.
> >>>
> >>
> >> Why not provide an argument whose default is something given by
> tempfile()?
> >>
> >> Duncan Murdoch
> >>
> >>
> >>
> >>> Any suggestions appreciated.
> >>>
> >>> -Roy
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> **********************
> >>> "The contents of this message do not reflect any position of the U.S.
> >>> Government or NOAA."
> >>> **********************
> >>> Roy Mendelssohn
> >>> Supervisory Operations Research Analyst
> >>> NOAA/NMFS
> >>> Environmental Research Division
> >>> Southwest Fisheries Science Center
> >>> ***Note new street address***
> >>> 110 McAllister Way
> >>> Santa Cruz, CA 95060
> >>> Phone: (831)-420-3666
> >>> Fax: (831) 420-3980
> >>> e-mail: Roy.Mendelssohn at noaa.gov www: http://www.pfeg.noaa.gov/
> >>>
> >>> "Old age and treachery will overcome youth and skill."
> >>> "From those who have been given much, much will be expected"
> >>> "the arc of the moral universe is long, but it bends toward justice"
> -MLK
> >>> Jr.
> >>>
> >>> ______________________________________________
> >>> R-package-devel at r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>>
> >> ______________________________________________
> >> R-package-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >
> >
> > --
> > Joris Meys
> > Statistical consultant
> >
> > Department of Data Analysis and Mathematical Modelling
> > Ghent University
> > Coupure Links 653, B-9000 Gent (Belgium)
> > <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-
> 9000+Gent,%C2%A0Belgium&entry=gmail&source=g>
> >
> > tel: +32 (0)9 264 61 79
> > -----------
> > Biowiskundedagen 2017-2018
> > http://www.biowiskundedagen.ugent.be/
> >
> > -------------------------------
> > Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> >
> >         [[alternative HTML version deleted]]
> >
> > ______________________________________________
> > R-package-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>



-- 
Joris Meys
Statistical consultant

Department of Data Analysis and Mathematical Modelling
Ghent University
Coupure Links 653, B-9000 Gent (Belgium)
<https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium&entry=gmail&source=g>

tel: +32 (0)9 264 61 79
-----------
Biowiskundedagen 2017-2018
http://www.biowiskundedagen.ugent.be/

-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

	[[alternative HTML version deleted]]



More information about the R-package-devel mailing list