Workflow for project-specific packages

When developing code within an R project it's natural to produce many functions that abstract operations that are more-or-less specific to the current project. My typical workflow is to organize functions in files in an R/ directory and source the ones that are needed within each script. From experience, this seems like a standard workflow.

There are times where I end up producing enough functions for a project that dependencies start to emerge between them. It's about this time that I begin to consider migrating these functions into a package.

When doing so, I tend to separate the functions and the scripts into different git repositories. The functions move outside the project. This make sense in one way: the project involves the analysis, and the package provides tools for that analysis. However, this package is inextricably bound to this project in particular (with no eye at present towards making the functions more generally useful).

Has anyone experimented with other workflows that involve packages that are more clearly subordinate to a project? I am about to start tinkering with a workflow where the R/ folder is replaced with a <project_name> subdirectory that contains a package. Especially if the project is organized around renv then my project-specific-package won't be installed globally.

In principle, I understand that projects and packages are distinct entities for a reason. Pragmatically, as someone who is a researcher/experimentalist/analysist first and a package developer ... 20th? ... I want projects to "own" packages, in a sense.

I do not have a question per se, but I wanted to hear about other people's workflows and general reactions to the "package-nested-in-project" workflow.

This topic was automatically closed 42 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.