Repository navigation
Conversation
threexc
changed the title
1ca9f20 to
f7c4321
Compare
|
Can't we get the list of python configuration we should build in Then in |
I really like the idea of having that info in |
| python-matrix: | ||
| description: Also compute the matrix output, querying PyPI for the interpreters upstream builds each version for. | ||
| required: false | ||
| default: false |
There was a problem hiding this comment.
The idea was to set it to false by default as part of a gradual rollout to our workflows - the skills/ directory gives the LLM instructions for converting workflows to use a dynamic matrix as it updates them to build new versions. That way existing workflows keep working as expected until there's a reason to trigger them again.
| python-exclude: | ||
| description: Space-separated interpreter tag globs (e.g. "cp39 cp315*") never to build. | ||
| required: false | ||
| default: '' |
There was a problem hiding this comment.
python-exclude is actually important. And I guess the default value should be "cp39 cp310 cp311" at least since we decided to follow numpy convention to build only for 3.12+. I noticed a lot of packages still build for 3.9 3.10 and 3.11 so it is actually important to have this as a default
There was a problem hiding this comment.
Do we still want to follow numpy, or should we let the dynamic matrix follow each project from now on, excluding versions only when they don't build for riscv64 (or for another related reason)?
I like that idea. I'll work on a change to do that instead.
|
python-wheels currently has a narrow, manually-set list of Python versions to build for, but this is often at odds with upstream projects. Instead, rework check_versions.py to check and define a list of upstream's targeted Python versions in each package's docs/packages/ file, then adjust pending_versions.py to pull directly from the data populated by check_versions.py. We may still want to exclude certain versions for a given package (for example, to omit an older wheel that won't build on riscv64), so allow passing flags to the script to indicate these versions. Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Add support for taking a dynamic list of Python versions as an input when a new workflow parameter, 'python-matrix', is set true, based on the output of scripts in the ci_scripts/ directory. Default to an empty list if nothing is provided. Also support 'python-exclude' for cases when we want to omit versions for various reasons. Modify build-falcon.yml as a sample case. Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
…trix logic Provide better instructions based on the changes in ci_scripts/ and .github/workflows, to support dynamic Python matrix generation and situational excludes. Make sure that any automated rework to existing workflows is gradual, i.e. it occurs when a workflow is modified during meaningful work, instead of bulk editing all workflows now. Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
f7c4321 to
4e76952
Compare
|
Updated to address most feedback. Still left the questions about default versions to exclude and default python-matrix state. |
Instead of hard-coding our target versions, change our code in
ci_scripts/,.github/workflows,skills/, anddocs/development.mdto support dynamically deriving a target Python build matrix for each package, which can be rolled out gradually as updates are performed (instead of having to bulk rewrite and trigger all existing workflows). Now, when a workflow sets thepython-matrixparameter totrue, useci_scripts/pending_versions.pyto derive the list based on what the release targets upstream. Also allow us to extend/exclude the lists on a per-package basis by setting thepython-extendandpython-excludeinputs.Modify
build-falcon.ymlas a test change. The skills files indicate that the rollout should be gradual, so our existing automation can convert workflows over time as new releases are built.