Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR carries on the work by @pmolodo (#355) to add a custom package order. This is essentially a generalization of the
version_split
package order, which provides better functionality for splitting versions within specified ranges, instead of only allowing a single split, asversion_split
does. This makes the package orderer useful outside of the extremely narrow band of intended uses that the version_split package order was intended to solve.CustomPackageOrder
This adds support to explicitly specify the way versions should resolve, while still providing flexibility for ranges.
For example consider the following package
houdini
:And consider the following optional plugin
plugin
that has variants (all latest versions of Houdini):But let's consider that the latest version of Houdini is not well tested and we do not know if our pipeline will behave properly with these latest versions. On top of that, consider that we want
houdini-19.5
to be the default.Examples:
rez env houdini
resolves tohoudini-19.5.632
(not latest)rez env houdini plugin
resolves tohoudini-19.5.679
(19.5 version that is compatible with plugin)rez env houdini-20
resolves tohoudini-20.0.413
(not latest 20)rez env houdini plugin
resolves tohoudini-20.0.528
(20 version that is compatible with plugin)This is hard to achieve without explicit presets, which makes preference of second order dependencies very difficult to resolve without taking advantage of the graph evaluation of rez. More information here: https://docs.google.com/document/d/1zy3ydSpHWgvatFS--L2PK7AwwOaowr1sdI9B_2eNtFc/edit?usp=sharing
We can now achieve that with the CustomPackageOrder:
In the above package orderer, we see that we prefer
19.5.632
if no other version constraints are put on it. If 19.5.632 is not suitable (as in the case ofplugin
not having a requirement match) then we prefer the latest version that fits the VersionRange of19.5
. If that is not suitable, then we prefer20.0.413
to causehoudini-20
to resolve to a less-than-latest version of Houdini 20.Lastly, the CustomPackageOrder may take an argument to determine how versions within those version ranges are sorted, e.g. with pypa sorting.