Ensure additional key versions are prioritised over number of additional keys in version_priority solving

[jonahjnewton]

When resolving with version_priority solving, the number of additional keys is prioritised over the version number of additional keys.

This causes unexpected behaviour, especially when using package orderers.

Take the following example orderer from the docs: https://rez.readthedocs.io/en/stable/package_orderers.html#version-split

package_orderers = [
    {
       "type": "version_split",
       "first_version": "2.7.16",
       "packages": ["python"],
    }
]

If I have a package named pipeline with two variants, [["python-2.7.16"], ["python-3.7.4"]], and I run rez-env pipeline, then it will correctly resolve the python-2.7.16 variant based on the package orderer.

However, if I add another package to the variants, then we get unexepected behaviour.

1. If I change the variants to [["python-2.7.16", "other_package"], ["python-3.7.4"]], and run rez-env pipeline then the larger number of additional keys in variant 0 causes it to be pushed down in priority, and the python-3.7.4 variant is resolved (even though we specify that python-2 should be prioritised). If we run rez-env pipeline python, then python is recognised as a requested key rather than an additional key, and the python-2.7.16 variant is resolved.

2. More unexpectedly, if I change the variants to [["python-2.7.16"], ["python-3.7.4", "other_package"]], and run rez-env pipeline then the smaller number of additional keys in variant 0 brings it back up in the priority, causing the python-2.7.16 variant to be resolved again.

• Even more unexpectedly, even without the custom package orderer, this same logic occurs with the above variant setup, since the smaller number of additional keys causes the python-2.7.16 variant to be resolved over the python-3.7.4 variant.

To continue to ensure that unnecessary extra keys are not included, but the versioning of common additional keys is correctly respected, my solution is to separate common from non-common keys across all variants, and rework the sort ordering to ensure the correct version always takes priority, then prioritise based on non-common additional keys which were identified in the request, then the lowest number of additional keys. I believe this results in more robust and deterministic logic in which we make sure we are always getting the variants that make sense and are most correct.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: jonahjnewton / name: Jonah J. Newton (18b8880, 2c70287, 17ee8d5, a204a64, cd10edd, dd68842)

[jonahjnewton]

An important edge case I've found here:

With the example scenario in the PR description and the logic of this PR, if we have the variants [["python-2.7.16"], ["python-3.7.4", "other_package"]] and run rez-env pipeline, it will correctly return the python-2.7 variant.

Even if we run rez-env pipeline python other_package, it will still resolve the python-2.7 variant, and add other_package to the resolve at the end.

However, if we run rez-env pipeline other_package python/rez-env pipeline other_package, it forces the variant with other_package in it before getting to python, resolving the python-3.7 variant.

This feels intended as since other_package is specified earlier in the request, it takes precedence and the common dependency is preferred, but is just something important to note.