Circular env should use latest Plone version constraints

[mauritsvanrees]

The circular check always fails on Plone 6.0 because there is a cyclic dependency between plone.api and Products.CMFPlone. See test failure in a collective.honeypot PR. This was fixed long time ago in 6.1 and 6.2.

If the test matrix is configured for Plone 6.0-6.2, I think it makes most sense to use the 6.2 constraints in this env. I have manually done that here in that PR.

Does this make sense?

[gforcada]

I noticed that in some other collective package some time ago but forgot to report or fix it 😅

[gforcada]

Now that I have a look, plone.meta is right... its matrix definition is:

TOX_TEST_MATRIX = {
    "6.3": ["3.14", "3.13", "3.12", "3.11", "3.10"],
    "6.2": ["3.14", "3.13", "3.12", "3.11", "3.10"],
    "6.1": ["3.13", "3.12", "3.11", "3.10"],
    "6.0": ["3.13", "3.12", "3.11", "3.10", "3.9"],
}

and then on the code does:

test_matrix = get_test_matrix(options.get("test_matrix"))
plone_versions = list(test_matrix.keys())

single_constraints = f"-c https://dist.plone.org/release/{plone_versions[0]}-dev/constraints.txt"

So it gets the first plone version defined on the test matrix, if the defaults are kept, that would be 6.3.

On collective.honeypot though, the matrix is defined in .meta.toml as:

test_matrix = {"6.0" = ["*"], "6.1" = ["*"], "6.2" = ["*"]}

So here the first plone version is 6.0 🙃

We can sort the keys to ensure we get the highest, or document the docs that order should be strictly from high to low versions and that the highest value is then used for non-matrix tox environments.

I see both options (always the highest or allow manual sorting) as valid. Most of the times you will use the default matrix, which is already sorted, thus the problem is avoided, but if you manually define a matrix, then you might want to have this extra degree of freedom 🤔