[threexc]

Instead of hard-coding our target versions, change our code in ci_scripts/, .github/workflows, skills/, and docs/development.md to 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 the python-matrix parameter to true, use ci_scripts/pending_versions.py to 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 the python-extend and python-exclude inputs.

Modify build-falcon.yml as 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.

[luhenry]

Can't we get the list of python configuration we should build in check_versions.py and store that information in the docs/packages/<pkg>.yml per-version, like:

- version: 1.2.3
  python-versions: [3.10, 3.11, 3.14, 3.14t] // the versions that upstream builds for that package

Then in .github/workflows/_setup.yml we still only have docs/packages/<pkg>.yml to check. I like the idea of python-exclude to make sure we can still only have a subset for things that don't work. I don't get the need for python-extend: though as there shouldn't be anything we build that upstream doesn't build already.

[justeph]

Can't we get the list of python configuration we should build in check_versions.py and store that information in the docs/packages/<pkg>.yml per-version, like:

- version: 1.2.3
  python-versions: [3.10, 3.11, 3.14, 3.14t] // the versions that upstream builds for that package

Then in .github/workflows/_setup.yml we still only have docs/packages/<pkg>.yml to check. I like the idea of python-exclude to make sure we can still only have a subset for things that don't work. I don't get the need for python-extend: though as there shouldn't be anything we build that upstream doesn't build already.

I really like the idea of having that info in docs/packages/<pkg>.yml.

[justeph]

why false by default?

[threexc]

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.

[justeph]

same question as @luhenry: why would we need this one? if our goal is to mimic upstream?

[threexc]

Working on removing it.

[justeph]

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

[threexc]

Can't we get the list of python configuration we should build in check_versions.py and store that information in the docs/packages/<pkg>.yml per-version, like:

- version: 1.2.3
  python-versions: [3.10, 3.11, 3.14, 3.14t] // the versions that upstream builds for that package

I like that idea. I'll work on a change to do that instead.

Then in .github/workflows/_setup.yml we still only have docs/packages/<pkg>.yml to check. I like the idea of python-exclude to make sure we can still only have a subset for things that don't work. I don't get the need for python-extend: though as there shouldn't be anything we build that upstream doesn't build already.

python-extend was meant as an opposite to python-exclude, e.g. for if we wanted to build free-threaded wheels for a project which doesn't, or something like that. It's unnecessary future-proofing at this point though, so I'll remove it.