Added a hook to check whether provider exclusions for a specific python version match across relevant files #53355
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.
When working on #51756 , we initially planned to exclude the Tableau provider for Python 3.9. After quite a bit of trial and error, we eventually got it working. While this is admittedly a niche case, it quickly became clear that adding some automation and documentation around version exclusions would be helpful.
The first step to exclude a specific Python version for a provider, is to update three locations:
provider/pyproject.toml(in two different places)provider/provider.yamldev/breeze/global_constants.pyNote: There also is a fourth place in which the provider needs to be added, but this case is already covered by current tests.
In
pyproject.toml, two notations are used for excluding versions:>=3.10~=3.9, !=3.9(example from Cloudant provider)I have assumed the chance for
<=exclusions is rather low and thus not considered it.In
global_constants.py, the matrix logic derives the provider name as follows:common/sql), the name becomescommon.sql.amazon).>=3.10or~=3.9, !=3.9are treated as non-exclusions, as 3.10 is the lowest supported version. To handle this distinction, a constant calledMIN_SUPPORTED_VERSIONis used. This also ensures that when adding a new provider and having setrequires-python = ">=3.10"in the pyproject.toml the hook does not fail.Checks performed include:
classifierssection inpyproject.tomldoes not list any excluded version fromrequires-python.pyproject.tomlandprovider.yamlmatch and that this exclusion is also in the matrix indev/breeze/global_constants.py.Example output from the validation:
I've tested the logic with various test cases, but I'm happy to hear any feedback or corrections.
If this approach is deemed useful, I’d be keen to expand it further with documentation that clearly outlines how to exclude a provider for a specific python version.