Define workflow for updating a codemeta.json document

[cboettig]

It's not obvious how a user should best maintain their codemeta.json document. The workflow is pretty simple if the user adds no additional terms beyond what write_codemeta() guesses from README and DESCRIPTION file. In this case, a user should simply re-run write_codemeta() prior to any git tag release / CRAN release, etc.

Things are less obvious though if we start adding extra metadata (such as keywords) to the codemeta.json, as illustrated in the README. Then once, say, the DESCRIPTION file is updated, what is the best workflow to update codemeta.json to capture these changes (e.g. a new contributor, or new dependency) without loosing the additional elements of codemeta.json?

One could have an R script do this before release, e.g. a update_meta.R script reading:

library("codemetar")
cm <- create_codemeta(".")
cm$keywords <- list("metadata", "ropensci")
write_codemeta(cm)

but it seems a bit clumsy to have such an R script be the canonical document to update keywords. An ideal workflow would allow a user to edit the codemeta.json by hand, which is perhaps the most obvious way to extend the metadata.

Ideally codemetar could parse the DESCRIPTION and detect and adopt any changes in the resulting fields relative to any existing codemeta.json, but would otherwise defer to the existing metadata rather than lose it. (Should just require starting with any existing codemeta.json)

[nuest]

(Apologies if I'm missing something obvious here..)

Why not have the keywords in the DESCRIPTION file?

Have you considered plugging this update into documentation generation based on roxygen2 (and leveraging the @keywords tag?

[cboettig]

@nuest Brilliant! Yes, I've debated putting these into DESCRIPTION, I agree that's the most natural place for them. I haven't actually determined what's acceptable in terms of extending DESCRIPTION (I vaguely recall issue of having to remove Remotes: before submitting packages to CRAN; don't remember if that was because they didn't like new terms or merely since it was superfluous to a CRAN install)...

The roxygen suggestion is also excellent. Slightly less obvious than editing the DESCRIPTION, but definitely worth thinking about more.

[cboettig]

Going with DESCRIPTION as the default home for adding additional metadata fields, since this most naturally matches the expected workflow of maintaining an R package and crosswalking from DESCRIPTION to codemeta.json