yamllinter: raise if actual patch files are not coherent with conandata.yml

[ericLemanissier]

It can happen if:

• conadata.yml patches section reference some files which do not exist
• or if some patches exist in patches subfolder, but not in conandata.yml

---

• I've read the contributing guidelines.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the conan-center hook activated.

[ericLemanissier]

New detections:

• 1 patch listed in conandata.yml, but not present in patches folder: https://github.com/conan-io/conan-center-index/actions/runs/3766729317/jobs/6403536596#step:9:9907 => https://github.com/conan-io/conan-center-index/tree/8b3c7ac87fccd44d30ae18890823f386d3e12a02/recipes/rangesnext/all
• 17 patches which are not listed in conandata.yml (search for is not referenced in https://github.com/conan-io/conan-center-index/actions/runs/3766729317/jobs/6403536596):
  • Patch file 002-fix-event-destruct.patch is not referenced in recipes/co/all/conandata.yml
  • Patch file 0003-fix-diligent-core-include-paths.diff is not referenced in recipes/diligent-tools/all/conandata.yml
  • Patch file support-SPV_KHR_fragment_shading_rate.patch is not referenced in recipes/diligentgraphics-spirv-tools/all/conandata.yml
  • Patch file 2.3.3-0001-fix-find-asio-and-tinyxml2.patch is not referenced in recipes/fast-dds/all/conandata.yml
  • Patch file fix-mingw-msvc2015-export-assert-fail-6.1.0.patch is not referenced in recipes/fmt/all/conandata.yml
  • Patch file fix-install-6.0.0.patch is not referenced in recipes/fmt/all/conandata.yml
  • Patch file 0021-typedef-clockid.patch is not referenced in recipes/folly/all/conandata.yml
  • Patch file 0001-meson-win32.patch is not referenced in recipes/fontconfig/all/conandata.yml
  • Patch file 0001-remove-explicit-stdlib-setting.patch is not referenced in recipes/g3log/all/conandata.yml
  • Patch file cmake_install.patch is not referenced in recipes/hazelcast-cpp-client/all/conandata.yml
  • Patch file 0002-ign-tools-1.2.0-cmake-fixes.patch is not referenced in recipes/ignition-tools/all/conandata.yml
  • Patch file 0001-ign-tools-1.0.0-cmake-fixes.patch is not referenced in recipes/ignition-tools/all/conandata.yml
  • Patch file fix-not-declared-dumb_stringstream-7.1.1.patch is not referenced in recipes/libpqxx/all/conandata.yml
  • Patch file fix-not-declared-dumb_stringstream-7.0.1_to_7.0.5.patch is not referenced in recipes/libpqxx/all/conandata.yml
  • Patch file fix-apple-clang-compilation-7.4.0.patch is not referenced in recipes/libpqxx/all/conandata.yml
  • Patch file fix-missing-limits-include.patch is not referenced in recipes/libpqxx/all/conandata.yml
  • Patch file 1.4.18-0003-secure_snprintf.patch is not referenced in recipes/m4/all/conandata.yml

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ericLemanissier]

This is still alive, back off !

[prince-chrismc]

Because this inspect the contents of the recipe is more appropriate for the hooks https://github.com/conan-io/hooks/blob/2e7cac85494fd4ec5134aae5af504ed35174c0d7/hooks/conan-center.py#L465

Linters should focused on specific files and syntax correctness but the structure or files are the hooks. That being said it's unclear how these will evolve so I am not sure if this should be put on hold.

EDIT: I put this on our weekly discussion list

[ericLemanissier]

Because this inspect the contents of the recipe is more appropriate for the hooks https://github.com/conan-io/hooks/blob/2e7cac85494fd4ec5134aae5af504ed35174c0d7/hooks/conan-center.py#L465

ok. I tend to go to linters by default, because the way errors show-up in github is way more convenient and efficient than hooks errors and (even worse) hooks warning. That said we could start using a fixed format reporting errors and warnings in hooks, add a github workflow which exports the recipes, and code a problem-matcher. Then hooks error would show-up on github UI too.

Linters should focused on specific files and syntax correctness but the structure or files are the hooks. That being said it's unclear how these will evolve so I am not sure if this should be put on hold.

I had no idea about this "1 file" inspection rule. genuine question: what makes the number of files inspected relevant in choosing to implement a check as a hook as opposed to a linter ?

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ericLemanissier]

Still alive, you bot