[R-pkg-devel] implications of staged install for data processing packages
georg|@bo@hn@kov @end|ng |rom m@nche@ter@@c@uk
Fri Jun 28 17:10:50 CEST 2019
You need to give details what exactly gets you into trouble and about your use case, since any advice would be conditional on making assumptions about that. It is usually a bad a idea to have a function working on a hardcoded full filename. You will thank yourself later if you at least make it argument to your function(s). It can have for default value the one that is currently hardcoded.
Please note that your use case does not seem inherently related to staged installation.
"Hardcoded" in the context of staged installation does not refer to any hardcoded path
but to those paths that contain the temporary installation directory. Such paths can be obtained,
for example, with calls to system.path(), as illustrated by Tomas.
From: R-package-devel [mailto:r-package-devel-bounces using r-project.org] On Behalf Of Florian Oswald
Sent: 28 June 2019 09:17
To: r-package-devel using r-project.org
Subject: [R-pkg-devel] implications of staged install for data processing packages
I ran into trouble with the changes starting to come in with R3.6 stemming
from the new staged installation, which checks and errors on hard coded
paths in R code. I understand there is an opt out, but still want to know.
here's the blog post:
I have several packages which look like that:
1. large messy dataset stored on disk as `filename`, maybe a csv.
2. R package has a function `clean(filename)` which reads the data and
brings it into useable form
3. R package does analysis
4. R package exports results
`filename` is hard coded. What is the proper way to do this instead? Should
I store the inital raw data inside the R package in `/inst`? These things
are typically very large, so I like to decouple the raw data from the
package (easier to share).
thanks for any suggestions!
[[alternative HTML version deleted]]
R-package-devel using r-project.org mailing list
More information about the R-package-devel