Guidance for contributors #63
Comments
|
Great point, a few additional thoughts: Thinking what we can do that would be as "config-free" as possible: Seems like maybe we should first check the URL in DESCRIPTION. If that is a Github URL, we should assume that as the base URL for any GH links, rather than using any of the git origin information. If that is unset, we could leave things as is for now (because really, every DESCRIPTION should set a URL), but I guess the better thing to do would be to call the GitHub API to decide if this is a fork, and if so, what the parent repo path is. |
|
👍👍 So for a very independent fork like https://github.com/jeroen/jsonlite there would be no problem thx to URLs in DESCRIPTION. I actually wonder if one could just output an error if there's no URL in DESCRIPTION? Enforcing good practice. |
|
Logic I want to implement in dev:
|
|
Should the code use the URL in DESCRIPTION no matter what to avoid 1) a wrong URL in DESCRIPTION 2) using the GH API? In that case that branch would nearly be ready to be merged into dev, I'd just need to document that and also to try and be a bit more exhaustive for DESCRIPTION files with several URLs. |
|
Now that I think of it having an error when there's no URL in DESCRIPTION is a bad idea, it should be a warning. 👼 |
|
Maybe this can be closed now if the logic in 8c43fce is not wrong.
|
|
oh and so there's no use of GitHub API to find out whether the repo is a fork. |
|
Sounds good to me! feel free to close when ready. |
* add pre-commit hook for DESCRIPTION vs codemeta.json * oops had forgotten the dependencies 😱 * had also forgotten to import the function * puts the code in the right place and documents what the first call to write_codemeta will do * add rOpenSci and myself as authors * remove MIT licence * change licence * add that the code is GPL-3 * replaces devtools with usethis where possible * mostly French snobism 😉 * add uses_git origin * cf #62 * #62 * only adds hook once! * start using desc cf #41 * various fixes * better example? * document * removes reference to deleted function * cf #63 * cf #64, parses more possible roles * updates codemeta.json in particular more people/orgs appear * start work on opinions cf #76 * document * oops * oops again * gives opinion when verbose=TRUE and otherwise just uses robust code * cleans up tests * more tests of plain authors&maintainer * work on tests * corrects documentation * better if the pkg exists 😁 * update codemeta * adds a message to get a devtools release question * fix? * new try * removes httr dependency in favor of crul cf #83 * checks URLs in DESCRIPTION cf #68 * oops fixes test * uses dev version of jsonld * adds coercion to character to repair bug introduced by jsonld new version cf #88 * clean up cache * yay encoding * close #84 by deleting now useless licences.R file * appveyor * oh, Appveyor * start filling NEWS.md * better checks when several URLs * more space * generate review metadata cf #23 * oops * cf #63 * @jeroen said that this might help 🙏 * thanks again @jeroen * test on patched R version * CRAN and Bioconductor links for dependencies cf #81 * add tests of dependencies URL creation * add canonic URL for the package itself cf #81 * borrows jsonlite code cf #84 * makes it a bit more specific * badge parsing cf #130 * uses badge parsing function in guess_metadata * opinions about README cf 98 * add check of provider cf #81 * oops * oops again * R CMD Check NOTEs * oops * update contributor list cf #95 * several relatedLinks cf #99 * add the URL only once * oops repairs test * update NEWS * add ability to provide relatedLink for packages installed from CRAN or Bioconductor * add link to commit if available * only one maintainer currently cf #109 * oops this was wrong! * mmmh there was a mistake here * Travis fix? * remotes cf #96 * Travis fix? * export the badge extraction function cf #107 and update docs and correct a test * status as URL cf #102 * now one can extract lifecycle status * not only Travis CI as contIntegration cf #111 * update NEWs * update NEWS * repairs handling of additional terms cf #112 and adds corresponding test * correct test
If one creates a fork of a package like I've done now for
codemetarand modifies the DESCRIPTION to add a contributor or dependency one will have to update codemeta.json because it's best practice and also because of the pre-commit hook cf #59But if one does so, the codemeta.json will use the GitHub links of the fork.
Would it make sense to add some guidance about this to the docs, and maybe some code? My ideas
Have an option "doc_fork" or so in
create_codemeta, FALSE by default.It'd only change GH links if TRUE, otherwise it'd let them as they are, this way if one decides to document a fork, one would need to force it, and if one just wants to update codemeta.json in the context of a Pull Request, one wouldn't need to worry about the whole thing.
The text was updated successfully, but these errors were encountered: