Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: use SPEC 0 schedule for cibuildwheel #1912

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

mayeut
Copy link
Member

@mayeut mayeut commented Jun 30, 2024

As discussed in various issues, I think that cibuildwheel is in position where it might make sense to follow SPEC 0 schedule rather than the CPython schedule. This would allow to take advantage of new Python features faster (or without/ with less back ports).

This draft PR is:

  • to gather feedback on such a change
  • to check that indeed, every CI we support is ready.
  • preview what would change
  • if we want to follow-up with this, then, it might be a good thing to warn users ahead to let them update there workflows if need be (mostly for CI that do not come with python pre-installed).

The idea would be to switch to SPEC 0 in 2024Q4 after Python 3.8 EOL & Python 3.13 GA, thus dropping 3.8, 3.9 & 3.10.

.github/workflows/test.yml Outdated Show resolved Hide resolved
@mayeut mayeut force-pushed the nep29 branch 2 times, most recently from 4ba37cb to 1e899ff Compare June 30, 2024 15:58
@joerick
Copy link
Contributor

joerick commented Jul 2, 2024

I support this change. There is very little reason to hang on to older Pythons on the host side, when we can benefit from new features.

To be clear to anyone coming across this, we're talking about the version of Python that is used to run cibuildwheel. That is distinct from the versions of Python that we build wheels for, which would be unchanged by this.

@EwoutH
Copy link
Contributor

EwoutH commented Jul 11, 2024

I think it's very logical for a project like cibuildwheel to follow SPEC 0 on the host side.

@henryiii
Copy link
Contributor

henryiii commented Oct 7, 2024

Let's get 3.13.0 in, make a patch release, then I think this will be ready to merge?

@mayeut
Copy link
Member Author

mayeut commented Oct 8, 2024

then I think this will be ready to merge?

I was waiting for 3.13.0 final availability in GHA but maybe we don't care that much about that (or removing the allow-prereleases: true in tests)

@henryiii
Copy link
Contributor

henryiii commented Oct 8, 2024

Don't necessarily need to remove the allow-prereleases. The only time Python pre-releases is for upcoming Python versions, which you opt-into anyway. Maybe "3.x" or version ranges could be confused, but otherwise there's no harm in keeping it around. And it's really only our tests, users don't care or need GHA's 3.13.

@henryiii
Copy link
Contributor

henryiii commented Oct 8, 2024

(and, 3.13.0 is available AFAICT, it's just not shipped in manifests or runner images yet. But also I'm not talking about merging the instant we release, either ;) )

@mayeut mayeut marked this pull request as ready for review October 15, 2024 14:19
cibuildwheel/linux.py Outdated Show resolved Hide resolved
Copy link
Contributor

@Czaki Czaki left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good to me

@henryiii
Copy link
Contributor

Should we add a warning to cibuildwheel running on Python 3.8-3.10 stating that the host Python needs to be upgraded to keep working with the next version of cibuildwheel? Unlike a normal Python package, you don't want to get silently stuck on an older version of cibuildwheel.

@joerick
Copy link
Contributor

joerick commented Oct 18, 2024

Yeah, that's a good idea. I just checked and a decent number of projects just write pip install cibuildwheel into their build scripts - those people would miss out on cibuildwheel upgrades if their python is oldish.

@joerick joerick added the Hold for future release This PR might be complete, but is scheduled to be merged in a future release. Don't merge yet. label Oct 27, 2024
@joerick
Copy link
Contributor

joerick commented Oct 27, 2024

We're talking in #2047 about holding this until a v3.0 release, but we'll want to get #2052 and perhaps other changes in before then, so I've added a label to that effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Hold for future release This PR might be complete, but is scheduled to be merged in a future release. Don't merge yet.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants