Use preinstalled Python 3 for cibuildwheel action

[abitrolly]

There is at least 3.7 in every runner
https://github.com/actions/virtual-environments

[henryiii]

18.04 has 3.6. And using setup-python is recommended on GHA, and this example¹ is more about showing generally how to use cibuildwheel, not the specifics of what's installed in a runner. You really should use pipx, or our custom action², etc. if this was about GHA. GHA recommends using setup-python if you need Python. If you are on a different CI system, the same steps apply: make sure you check out code, make sure Python is available, run cibuildwheel. This means we should show setup-python here.

Also, I know we added python3 to setup-python on Windows, but I'm not sure it's available without setup-python on Windows, I think not.

Footnotes

1. The readme one. ↩

2. We have an active PR to improve setup-python to work better with our action, FYI. ↩

[abitrolly]

18.04 has 3.6.

And cibuildwheel is compatible with 3.6

cibuildwheel/setup.cfg

Line 43 in cc56a14

python_requires = >=3.6

And using setup-python is recommended on GHA

"because it ensures consistent behavior across different runners". For me setup-python is probably needed to setup python-dev and all dependencies for binary extensions properly, but it looks like cibuildwheel uses its own environment control. Having setup-python makes scenarios less clear as it may give a false impression that it is how Python version for wheel is selected.

[abitrolly]

python3 to setup-python on Windows, but I'm not sure it's available without setup-python on Windows

windows-latest has it https://github.com/yakshaveinc/python/runs/6945448591?check_suite_focus=true

[henryiii]

And cibuildwheel is compatible with 3.6

It would be nice to change that, though! Hopefully if setup-python gains better composite actions support, we can drop 3.6 from the host.

Don't we want consistent behavior across runners? And if we tell people to use python3, we'll be getting an older and less consistent Python version. And if people really are using cibuildwheel on GHA, they should ideally be using the action. Which uses pipx. Which currently uses the (inconsistent) built-in Python 3 (albeit with venvs, etc). So technically it's not that different (and part of why we still support 3.6 on the host). We are actively trying to fix this, though, by adding a feature to setup-python for composite actions.

I'm not terribly against it but I think the current method is a bit closer to best-practices for GHA examples. Put me down as -0.1.

[henryiii]

less clear as it may give a false impression that it is how Python version for wheel is selected

It's something you do have to be at least a little aware of, and I've been in favor of making it more obvious (by printing the host Python version in the initial printout), but I'm not in the majority there. It was much better before v4 started forcing you to specify a version (discussion in actions/setup-python#421), as leaving it verisonless was clearer.

[abitrolly]

Don't we want consistent behavior across runners? And if we tell people to use python3, we'll be getting an older and less consistent Python version.

Cover all runners with a test that builds simple wheel will signal when this version becomes a problem. Speaking of this test, why there are no tests running with GHA?

So technically it's not that different (and part of why we still support 3.6 on the host). We are actively trying to fix this, though, by adding a feature to setup-python for composite actions.

And switching to 3.6 would leave out builds without GHA on Ubuntu 18.04 (https://packages.ubuntu.com/bionic/python3).

The project already can bootstrap needed Python versions to run code inside it, so if coding with 3.6 is that painful, it might be possible to keep the bootstrap part minimal (and probably reused from outside) and run the rest of cibuildwheel with that Python. That would come with a small performance penalty though.

[joerick]

Calling setup-python would seem to be a best-practise kind of thing. I'd prefer to keep it. The github example workflows all seem to use it.

e.g. https://github.com/actions/starter-workflows/blob/main/ci/python-app.yml