Help researchers track results in manuscript back to source code. about unconf18 HOT 6 OPEN

Awesome! I'm learning so much and the unconference hasn't even started! Thank you!

from unconf18.

This is a great approach. It is of course related to #42, but potentially applies very different workflows. For projects where I'm not compiling the final output I like to have an outputs folder which has not only images and tables but an Rmd or text file output with all the essential quantitative values that make their way into the manuscript. Usually things can be traced back from the filenames there.

from unconf18.

drake + literate programming may help a bit. Drake's main example's has a data analysis workflow with this R Markdown report at the very end. The active code chunk has calls to loadd(fit) and readd(hist), which serve to

1. Fetch targets from the cache when the report compiles, and
2. Tell drake to treat fit and hist as formal dependencies (so drake::make() rebuilds the report.html if there is a change to fit or hist.) Even if you don't care about Make-like build management, you can still see where these data objects fit into the pipeline.

In that sense, using and annotating an artifact are one in the same.

I am curious to know the views of @gmbecker and @duncantl on the original issue. As I understand it, provenance is a major focus of trackr, RCacheSuite, and CodeDepends.

from unconf18.

Edit: as for linking data objects back to the source code, the dependency graph shows the functions that generated fit and hist. That's an important point I forgot to add. The previous graph excluded functions. See below for the full graph.

from unconf18.

It's such a fantastic crowd! I wish I could be at unconf to soak up more knowledge in person.

from unconf18.

Summary:

• Relates to #58, drake (@wlandau), trackr, RCacheSuite, and CodeDepends (linked above; @gmbecker and @duncantl).
• drake comes up very often. Should we discuss to become more familiar with it?

from unconf18.