allow user to specify list of base Python versions, to bypass retrieving from https://endoflife.date

[zacharyburnett]

another idea to build on top of #392, for users who might want to constrain the list of "testable" versions for whatever reason

[Cadair]

I kinda see the use of this, but if you don't want to rely on endoflife.date surely you can just list out the python versions in the envs?

[zacharyburnett]

oh in the envs! Good idea I'll write that up

oh you meant in envs: not in the environment variables. That might still be a good idea though

[zacharyburnett]

oh never mind; you can't pass environment variables directly to a workflow_call. I think this change is still useful in the situation where you do want dynamic versions, but only narrowed from a specific base list of versions (say in case you don't want a new Python version to immediately break CI workflows so you keep a lagging list of versions, but you still want it to be tested in a devdeps workflow or something similar)

[Cadair]

I guess I don't really know why you would do this:

envs:
  - py*-test
    python-versions: ["3.11", "3.12", "3.13"]

rather than this:

envs:
  - py311-test
  - py312-test
  - py313-test

This feels like feature creep to me, when there's a way of comparable verbosity already?