From R Packages (2e) - 5 Fundamental development workflows we've seen the advice:
A directory that is an RStudio Project will contain an
.Rproj
file. Typically, if the directory is named “foo”, the Project file isfoo.Rproj
. And if that directory is also an R package, then the package name is usually also “foo”. The path of least resistance is to make all of these names coincide and to NOT nest your package inside a subdirectory inside the Project. If you settle on a different workflow, just know it may feel like you are fighting with the tool
Within our teams we are very often finding that we're working on small, very domain specific sets of functions, along with scripts, notebooks, reports, shiny-apps and plumber apis which are very closely tied to those functions.
In these situations, we've gotten into the habit of putting:
- all those connected things in a single git repo (which ensures they get versioned together),
- using a
/package
folder inside that repo for the functions (using DESCRIPTION,/R
,/man
inside there) - using top level
/scripts
,/reports
,/apps
and/apis
folders for the consumers of the package functions - using
renv
on the entire repo
This seems to be working OK for us - especially as we've got build pipelines which auto-increment the package version number, deploy that to our local CRAN, and then auto-deploy the reports and apps using that latest checked-in package.
The only tool fighting we seem to be doing is that people do have to remember to use e.g. devtools::load_all("package")
rather than just devtools::load_all()
But I'm wondering:
- what "better" ways of structuring this are there?
- what tools should we be fighting that we clearly are missing?