You can't always get what you want, but
But if you try sometime you find
You get what you need
(M. Jagger, K. Richards, 1969, You Can't Always Get What You Want (from Let it Bleed), ABKCO Records, London, United Kingdom.)
I'd approach this the same way as any other problem in R
—functionally, f(x) = y, where
- x is the current dataset
- y is a printed report of some derivation of the dataset
- f' is a workflow in
R
that can process x to a pdf
file
where f' is subject to the constraint that it must be invoked by a user who is assumed to be solely in possession of x and incapable of invoking f' from either an R
console or IDE
(such as RStudio desktop, cloud or other, similar product).
The problem resolves to the design of f(f') where f is a composite of some facility that may be a wrapper R
script, desktop app, SaaS or a combination.
By hypothesis a bare R
script is infeasible. A desktop app is unmaintainable over the long run unless it has no operating system or library dependencies and SaaS is also, by hypothesis, unmaintainable by the user. What is left is a containerized software application to operate as a virtual virtual machine.
Ideally, opening the container would run the app with a single argument—the location of the current dataset. Still, the human factor reliability metric for placing the dataset in the correct location is open to doubt.
One consideration is the projected lifetime of the report. In my organizational experience, these tend to track the tenure of the most senior manager who regularly acts of them. That will vary by organization. For a relatively stable organization, such as a government agency, this can be expected to span many years. For a start-up, conversely, it may be measured in months.
For the short-tenured case, platform obsolescence is less a concern. For the long-term, consideration might be given to a closed system, such as a containerized app running with a Linux OS all flashed to EPROM on a Raspberry Pi with a thumb drive reader.