From R Packages (2e) - 5 Fundamental development workflows we've seen the advice:
A directory that is an RStudio Project will contain an
.Rprojfile. Typically, if the directory is named “foo”, the Project file is
foo.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
/packagefolder inside that repo for the functions (using DESCRIPTION,
- using top level
/apisfolders for the consumers of the package functions
renvon 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
But I'm wondering:
- what "better" ways of structuring this are there?
- what tools should we be fighting that we clearly are missing?