Python 3.11

[altendky]

Draft for:

• Wait for rework build matrix to a single workflow #30
• Needs a blspy wheel for 3.11

[arvidn]

iirc, there was also some other trick @richardkiss had to pull to get maturin to work on windows.

[richardkiss]

Note that a single binary is built for all python versions for a given platform. Because of this, I don't think it's actually necessary to check all versions of python.

[richardkiss]

As for the Windows-specific stuff, I'd recommend looking at how the windows build works elsewhere.

Ideally, we should serialize these process – create a wheel, export it as an artifact, then import that artifact by dependent testing and benchmark actions. This would let us build the wheel just once, and also test just that particular binary.

It would take a Github Actions wizard to do this for sure, but it's the right way.

[altendky]

I've done exactly that sequence in other projects and have commented on it at various points here, but I haven't taken it on myself to actually switch over here. Let alone for a dozen or whatever repos...

https://github.com/altendky/ciborg/actions/runs/363450564 is an example.

As to testing more Python versions, I personally default to testing the matrix we claim to support, until it gets onerous. I think that our support repos like this are low enough traffic and the tests are quick enough that the CI runtime overhead is negligible. In some sense there is added overhead in the CI setup complexity, but if we maintain it then we get the benefit of consistency across projects which is an alternative benefit.

[richardkiss]

I've done exactly that sequence in other projects and have commented on it at various points here, but I haven't taken it on myself to actually switch over here. Let alone for a dozen or whatever repos...

https://github.com/altendky/ciborg/actions/runs/363450564 is an example.

As to testing more Python versions, I personally default to testing the matrix we claim to support, until it gets onerous. I think that our support repos like this are low enough traffic and the tests are quick enough that the CI runtime overhead is negligible. In some sense there is added overhead in the CI setup complexity, but if we maintain it then we get the benefit of consistency across projects which is an alternative benefit.

A comment here... I think ideally you want to build the sdist first, and use just that as an input to build each wheel. That way, we have a high confidence that the sdist is being built and is legit.