Enable/ease/encourage projects using targets to become packages

[Robinlovelace]

Prework

• [x] I understand and agree to the code of conduct.
• [x] I understand and agree to the contributing guidelines.
• [x] New features take time and effort to create, and they take even more effort to maintain. So if the purpose of the feature is to resolve a struggle you are encountering personally, please consider first posting a "trouble" or "other" issue so we can discuss your use case and search for existing solutions first.

Proposal

This is just a general idea that can be worked-up into an example with reproducible code in a test repo if promising. It arises because of the following observations:

• Converting projects into working R packages is a viable workflow that helps improve reproducibility
• targets uses some elements of packages, for example the convention that functions go in the R folder
• The aim of researchers who develop not only new findings but also new tools (e.g. in the form of new functions) is often to publish the tools in a reproducible form, e.g. in an R package
• I imagine that a few standard tweaks (e.g. ignoring files like _targets.R in the build with functions like usethis::use_build_ignore()) to well-organised projects that use the targets package could be used to make them easier to become fully fledged packages that could eventually pass devtools::check() and even be published on CRAN.

Assuming that this issue hasn't already been addressed (I've not looked that hard into it), I can think of two mutually compatible ways that it could be addressed:

• Document the work needed to convert projects using targets into packages in the documentation
• Add helper functions, e.g. tar_packagize(), to add standard set of changes (e.g. to .Rbuildignore) to help the transition from a targets project to a fully fledged package that can be installed by others to maximise impact and reproducibility

Just an idea, hope it's of use/interest and happy to work it up and contribute if you think it's a goer.

[wlandau]

It's an interesting and a persistent topic. targets is certainly opinionated about a lot of programming practices, particularly the emphasis on functions. And with tar_option_set(envir = getNamespace("yourPackage"), you can set up a pipeline as a package in such a way that targets still watches all your R functions for changes (see also import). However, targets deliberately tries not to nudge you into any specific decisions about how to organize files. Yes, the examples do use an R/ folder for function scripts, but that's minor, and there's no built-in nudge in the actual software. Beyond that, I think it's best to decouple targets from that whole discussion because it gets pretty involved. Example: https://milesmcbain.xyz/posts/an-okay-idea/. The research compendium is a related and more flexible construct: https://github.com/benmarwick/rrtools/.

[Robinlovelace]

Thanks for quick reply. Assumed it had been raised before, will take a look!

[Robinlovelace]

Heads-up @wlandau and anyone else interested in this topic, I've got a proof-of-concept package that uses targets: https://github.com/ITSLeeds/dftTrafficCounts

I'm setting this up because I want to make the functions available and I want to demonstrate how to process lots of data using the functions, but I don't want to process the data every time I rebuild the package. It's my first time using the targets package. First impressions: clean, simple, relatively intuitive.

If you have any feedback on this idea @wlandau or anyone (heads-up @MilesMcBain and @benmarwick - food for thought, apologies for tagging but thought this idea may be of interest given your article on +s/-s of packaging and the rrtools package). I think targets + package development are compatible and could allow the best of both worlds in terms of enabling others to use your code while building data intensive workflows in the same project, but can totally see @wlandau's point above about the importance of being 'workflow agnostic'. Thoughts welcome, would be interested in organising the code in the dftTrafficCounts project in a different way, as long as it supports rebuilding outputs that require processing of GB of data and the amazing modular re-running-when-needed capabilities of targets.

[wlandau]

Interesting, thanks for sharing and for exploring the use case. I have a couple suggestions and will post them as issues.

[wlandau]

Just added new package-tracking functionality with tar_option_set(imports = your_packages) (#239, #241). See https://wlandau.github.io/targets-manual/practice.html#packages for details.

[Robinlovelace]

Great work, many thanks @wlandau !