QA pins

[ale-rt]

When using qa.cfg we miss quite a lot of pins.
That causes the GHA to break all of a sudden.

It took me quite a lot of time to add the proper pins that span through Plone 5.1/Python2.7 to Plone 6, so I am sharing this here:

• https://github.com/collective/dexterity.membrane/pull/62/files

Probably those pins should be added to the relevant plone-*.cfg files.

[mauritsvanrees]

@wesleybl has been adding various pins during the years. Do you have an opinion here?

I guess the reasoning so far was that it is fine to get updated packages, so we get improvements in say flake8. But they should not cause version conflicts, which I guess is what your problem was. When that happens, we can add maximum or exact versions, especially for older Python or Plone versions.

Note that there are more ways to check (and fix) code quality these days:

• https://github.com/plone/code-analysis-action
• https://github.com/plone/code-quality

Also for running gh-actions with tox I have created https://github.com/collective/tox-action

[ale-rt]

Those are cool stuff, but lot of add on rely on the code analysis installed by this buildout.
Personally I whink the way to is https://pre-commit.com/.
It works on your repo and it works on GHA adding just two lines, see e.g.: https://github.com/collective/zpretty/blob/master/.github/workflows/tests.yml#L36-L37

[wesleybl]

I think if the package is a direct or indirect dependency of plone.recipe.codeanalysis [recommended], and the problem is that newer versions have removed Python 2 support, they should be pinned to qa.cfg.

If the problem is a conflict with the version pinned in Plone, it should be pinned in plone-*.cfg.

We also have to be careful not to pin things that are specific to our package. In such cases, it is better to pin to the package itself.

@ale-rt some packages you pinned in the example buildout are already pinned in qa.cfg or plone-*.cfg.