Proposal: synergising with rworkflows

[bschilder]

Dear usethis team,

Thanks for continuing to maintain and upgrade this incredible suite of tools! I wanted to reach out and make you aware that our team has developed a GitHub Action called rworkflows:
https://github.com/neurogenomics/rworkflows

rworkflows is a suite of tools (a template, an R package, and a GHA action) that aims to simplify the setup and maintenance of R developer-oriented GHA workflows, while also providing easy-to-change parameters without the user every having the touch the yaml scripts (which some users may find intimidating). For more details, you can read about rworkflows in our preprint.

While there's some overlap with usethis's GHA functionality, there's a couple of key differences:

• We use a single short workflow script to call the rworkflows action (see example here).
• Once added (via rworkflows::use_workflow) users never have to update their yaml script, because any changes/fixes to the rworkflows action will automatically be propagated to call users.
• The entire rworkflows action is version controlled using release tags.
• rworkflows has some additional features like building Docker containers and deploying them to Dockerhub.
• For a more detailed comparison of rworkflows, usethis, and biocthis you can check out our step-by-step tutorial.

I'm reaching out to your team to see if you would be interested in synergising our efforts to provide easy-to-use CI tools for R package development. Some potential avenues might include:

1. Adding an option to the relevant usethis::use_github_action* functions to call the rworkflows action. If interested, I'd be happy to make a PR to usethis to help implement this.
2. Making rworkflows an official standard for R package development, which would ideally come with long-term support to help maintain and improve rworkflows (currently this is being led by our lab at Imperial College London).
   I realize these are non-trivial things to ask, so I'm just proposing them here as topics of further discussion (if interested).

Feel free to either reply here or reach out to our team via email. If interested, I'd be more than happy to arrange a call with the relevant parties (possibly @jennybc @hadley @wch @jimhester ?):
Brian M. Schilder: brian_schilder [at] alumni.brown.edu | @bschilder
Alan E Murphy: alanmurph94 [at] hotmail.com | @Al-Murphy
Nathan G Skene: n.skene [at] imperial.ac.uk | @NathanSkene

Thanks again for all your remarkable efforts!,
Brian

[bschilder]

Hi again, just wanted to follow up and see if there was any interest in coordinating our efforts?

Thanks,
Brian

[hadley]

Sorry, we're not actively working on usethis at the moment, and for a big question like this we really need to have usethis loaded up in our heads.

[bschilder]

Thanks for the update @hadley, totally understand. Whenever your team has the bandwidth just let me know and I'd be happy to talk then.

In the meantime, I'll continue improving rworkflows. 🔧

All the best,
Brian

[bschilder]

Just an update @hadley, the rworkflows paper has been officially published.

Schilder, B.M., Murphy, A.E. & Skene, N.G. rworkflows: automating reproducible practices for the R community. Nature Communications 15, 149 (2024). https://doi.org/10.1038/s41467-023-44484-5

Therein it describes the motivation for creating rworkflows, namely improving reproducibility and transparency for R packages. It also lists the various stake holders that may benefit from rworkflows, including:

• developers: more immediate and comprehensive feedback on R package health (with minimal setup/maintenance of GitHub Actions).
• users: Docker containers with all system and R dependencies pre-installed, hosted directly on GitHub or on DockerHub.
• peer review journals: Offers a standardised way to assess the present robustness of an R package. Also avoids installation issues via the Docker containers, making it easier for reviewers to directly test the software.