codemetar and releases

[maelle]

Sorry if I missed this in the docs.

How could one ensure that codemeta.json is updated often enough?

• Could one hope to add a check to devtools::release checks? E.g. if "codemeta.json" exists the check would be to look when it was updated or just to ask the developper whether they updated it.

• Could the first use of codemetar::write_codemeta create a pre-commit hook like the one that usethis has for README.Rmd vs README.md (comparing codemeta.json update time to these of the files it uses as sources of information)

[cboettig]

Great question. I've been adding it to the README.Rmd, usually in a include=FALSE chunk so it doesn't show up. This isn't perfect, as users don't always re-generate README with each release.

Having a pre-commit hook to update codemeta.json if the DESCRIPTION file changes sounds like a pretty good idea to me! Interested in making a PR?

I basically assume changes to devtools::release checks are out of scope for us, at least for now. Could be part of a similar function in an ropensci::release() if we ever write a package to help automate onboarding submission??

[maelle]

Ok can you assign this issue to me? I hope that copying the way usethis makes its pre-commit hook will make it easy to solve. 🙏

I'm working on that package, it is here but 1) right now it only helps to add badges, I have clear priorities 😂 2) I'm not entirely convinced we could make people adopt an rodev::release instead of devtools::release but why not. It could also say "Send a blurb about the release to @sckott for the newsletter"!

[maelle]

Btw codemeta.json should change if DESCRIPTION or README.md change, right? (because of the status info contained in a badge in the README) Any other source of information I should take into account?

[cboettig]

assigned! yeah, technically that's right, though that might be annoying if README is changing in other ways

[maelle]

I'm using usethis exported function (and unexported code as well) which might be problematic reg LICENCE since usethis is GPL-3?

[cboettig]

Thanks. yeah, if we're copy-pasting the un-exported usethis code we would need GPL. If Jenny would export all the necessary code so we just pull if from usethis we don't need to change license. I'm fine either way.

[maelle]

I don't think there's a plan to export them and am not sure they'd be part of the possible package mentioned in r-lib/usethis#126

[noamross]

Note that I chatted with Jenny and Ben Marwick and both would be happy to have a use_codemeta() in usethis and rrtools. But Jenny said they didn't want to add dependencies, so codemetar would be in suggests for usethis and use_codemeta() would need to fail gracefully without it.

[maelle]

Oh nice!

The pre commit hook should still be in this pkg right?

[noamross]

I think we should put everything for use_codemeta() here for now and simply export it in usethis/rrtools. If and when usethis internals are pulled in to another package codemeta can import it.

[cboettig]

Nice, that's awesome! Sounds like we should alias write_codmeta() as use_codemeta() for consistency (and maybe push people towards using the alias)

[maelle]

No I think it'd be an alias for create_codemetasince use_blabla functions initialize stuff right? (it'd create the codemeta file, modify .Rbuildignore, add a pre-commit hook).

Not sure where updates should take place. 🤔 by hand with write_codemeta, as part of devtools::document, devtools::build_package, release...

I think it'd be the same workflow as for pkgdown website initialization & updates but this isn't totally wrapped yet, use_pkgdown doesn't do much.

[cboettig]

@maelle , yeah, write_codemeta() calls create_codemeta() to generate the information as an R list object and then writes it to disk as a codemeta.json file. (write_codemeta() also already updates .Rbuildignore, though doesn't yet add the pre-commit hook. I think that the hook should be opt-in, just like use_readme_rmd() doesn't automatically create a hook)). create_codemeta() by itself just creates the list object, it doesn't write anything to disk. ah semantics!

[maelle]

Aaah ok thanks for clarifying ☺

[maelle]

I think use_readme_rmd hook is compulsory if the project uses git? The hook doesn't even seem to be documented? https://github.com/r-lib/usethis/blob/master/R/readme.R 🤔

But happy to make this one opt-in or opt-out (my preferred option 😇)

[cboettig]

👍 ah, nice! we can do opt-out then if uses_git().

[maelle]

I updated my PR (in particular it turned out the code for creating the hook wasn't in the right function 🙈 ).

• Should I change the license?

• I have documented the hook but haven't made it opt-out, should I? Your last comment made me think you only wanted it to depend on git use @cboettig

• I'd gladly update the pkgdown website but I have I think the latest pkgdown version so there would be many small differences beyond the scope of this feature & its docs.

[maelle]

• Pre-commit hook added in dev via add pre-commit hook for DESCRIPTION vs codemeta.json cf #59 #60

• devtools::release reminder "probably fine" to add cf Add reminder to update codemeta.json to release()? r-lib/devtools#1754 (comment)

[maelle]

It turned out that one can add release reminders inside the package itself cf r-lib/devtools#1754 (comment)

I'd be in favor of adding the question rudely in a release-questions.R file (if no other release_questions can be found!) and of messaging the author it was done so rather than messaging them to paste the code in an R file. But I'm still thinking about how rude it'd be 🤔

[maelle]

Closing this because it is solved in dev 👼