search

ropensci-review-tools / pkgcheck

Check whether a package is ready for submission to rOpenSci's peer-review system
https://docs.ropensci.org/pkgcheck/
18 stars 6 forks source link

In vignette about adding checks, add whether one can consider the package to be installed #61

Open maelle opened 3 years ago

maelle commented 3 years ago

I.e. can checks used tools for installed packages or do they need to rather do some sort of parsing / static analyses?

maelle commented 3 years ago

Maybe also comment on/document the kind of metadata that's extracted by default and can be re-used in some checks.

mpadge commented 3 years ago

This will be partly addressed via #40, especially via local control of which tests are run. Currently the only tests requiring installation are the rcmdcheck and covr parts of goodpractice. They are nevertheless core parts, and pgkcheck currently presumes installation to be required.

That said, I personally suspect once user control of tests has been implemented (#40), I'll often resort to frequent static-only checks, only resorting to the full checks when i need to. Each check will have some kind of metadata - possibly along the lines of the values passed to the make_check() function of goodpractice, which have "description", "type", and "pattern" fields. Something along the lines of the meta-data approach there will likely be adopted here, with at least one additional meta-data flag, requires_installation. That would be really useful!

Maybe also comment on/document the kind of metadata that's extracted by default and can be re-used in some checks.

Yes indeed. That also requires documenting direct (or maybe "flat") tests versus hierarchical tests. Direct tests are like your has_scrap; hierarchical tests are like goodpractice and pkgstats. All of that needs documentation, but that can't sensibly be done until we know the ultimate form that these hierarchies are going to take. This issue definitely needs to remain open to address:

TODO