You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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)
The text was updated successfully, but these errors were encountered:
@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.
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
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 whatwrite_codemeta()
guesses from README and DESCRIPTION file. In this case, a user should simply re-runwrite_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 thecodemeta.json
, as illustrated in the README. Then once, say, the DESCRIPTION file is updated, what is the best workflow to updatecodemeta.json
to capture these changes (e.g. a new contributor, or new dependency) without loosing the additional elements ofcodemeta.json
?One could have an R script do this before release, e.g. a update_meta.R script reading:
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 existingcodemeta.json
, but would otherwise defer to the existing metadata rather than lose it. (Should just require starting with any existingcodemeta.json
)The text was updated successfully, but these errors were encountered: