I am currently developing a Golem Shiny app. Since it relies on a massive amount of raw data that needs transformation before use, I have separated this part of the workflow into a dedicated package for data preparation.
The preparation package is almost complete, and I can export all transformed data as a data.rda
file, which contains everything required by the Shiny app.
I have read Section 7.2 (Internal Data) from R Packages (2e) by Hadley Wickham many times. While I am comfortable using usethis::use_data(internal_this, internal_that, internal = TRUE)
within a single package, I am unsure how to handle a situation like mine—where the data.rda
file comes from another package but is meant to be used internally in the Shiny app package, and the shiny package itself also have an internal .rda
for intra-package purposes.
My current approach is:
- Migrate the
data.rda
file to theR/
folder of the Shiny app package. - Create a
Load_data.R
file that contains only one line of codeload(file = file.path("R", "data.rda"))
to load objects fromdata.rda
.
This seems to work, as the app can access the data. However, is this the correct approach? If not, what would be a more robust solution?
Any comment would be greatly appreciated!
I am currently developing a Golem Shiny app. Since it relies on a massive amount of raw data that needs transformation before use, I have separated this part of the workflow into a dedicated package for data preparation.
The preparation package is almost complete, and I can export all transformed data as a data.rda
file, which contains everything required by the Shiny app.
I have read Section 7.2 (Internal Data) from R Packages (2e) by Hadley Wickham many times. While I am comfortable using usethis::use_data(internal_this, internal_that, internal = TRUE)
within a single package, I am unsure how to handle a situation like mine—where the data.rda
file comes from another package but is meant to be used internally in the Shiny app package, and the shiny package itself also have an internal .rda
for intra-package purposes.
My current approach is:
- Migrate the
data.rda
file to theR/
folder of the Shiny app package. - Create a
Load_data.R
file that contains only one line of codeload(file = file.path("R", "data.rda"))
to load objects fromdata.rda
.
This seems to work, as the app can access the data. However, is this the correct approach? If not, what would be a more robust solution?
Any comment would be greatly appreciated!
Share Improve this question edited Mar 12 at 10:02 Grasshopper_NZ asked Mar 12 at 6:35 Grasshopper_NZGrasshopper_NZ 9195 silver badges15 bronze badges 11 | Show 6 more comments1 Answer
Reset to default 1According to Writing R Extensions, section 1.1.5:
The
R
subdirectory contains R code files, only.
There's an exception for sysdata.rda
, and .in
files, but nothing else.
That would indicate that using R/data.rda
would not be acceptable.
Instead, you could export the prepared data (or the data preparation function)
from your private data preparation package, and bake the results into sysdata.rda
for your primary package.
For reproducibility, write a script for those steps. In data-raw/sysdata.R
:
internal_this <- ...
internal_that <- ...
data("prepared_data", package = "rpackageforpreparingdata")
# Or: prepared_data <- rpackageforpreparingdata::prepare_data()
usethis::use_data(internal_this, internal_that, prepared_data, internal = TRUE)
firstpkg::my_dataset
without anything fancy like trying to exportsysdata.rda
internal-only data – r2evans Commented Mar 12 at 12:32load(.)
, why not just have it return the internal data itself? inside the data-package, the "internal data" is fully exposed anyway ... though this is about the same amount of work as my first comment but without the side-step of "this data is internal, but I'll export it another way". – r2evans Commented Mar 12 at 12:34sysdata.rda
), but maintenance anddevtools::
, and trying to dance around other internal-packages that really would benefit from the data ... I found that trying to do the dance you're doing was not worth the effort, and introduced more fragile components. My suggestion: if the package is already private, just export data the usual way. – r2evans Commented Mar 12 at 12:48