Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
maelle opened this issue Sep 14, 2021 · 2 comments
Labels
enhancement New feature or request

Comments

@maelle
Copy link
Contributor

maelle commented Sep 14, 2021

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

@maelle
Copy link
Contributor Author

maelle commented Sep 14, 2021

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

@mpadge
Copy link
Member

mpadge commented Sep 14, 2021

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

  • Structures for check metadata
  • requires_installation flag within metadata
  • Consistent system for hierarchical checks
  • Documentation of hierarchical checks
  • Documentation of all information currently extracted within checks (yet not necessarily "exported" to printed results)

@mpadge mpadge added the enhancement New feature or request label Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants