Encouraging 3.10 wheels on PyPI

Hello all, especially the release crew and PyPA!

How can we state more clearly that with 3.10rc1 out, projects should now release binary wheels for 3.10 on PyPI? (I’m assuming we do want to encourage that, of course.)

See the discussion for numpy, whose maintainers initially put 3.10 wheels on a different package index to clearly communicate that they are experimental. IMO that’s a mistake, and @hroncok’s write-up which convinced them is roughly something we should communicate somewhere to help 3.10 hit the ground running.

More broadly, would it be helpful to cover the development cycle and stability expectations in user-facing docs? Currently I could only find a FAQ entry, but I could expanded it to a whole page.

7 Likes

Strong +1 on me for encouraging more projects to publish binaries earlier in the release cycle.

As to how to get the message out, I don’t really have any good ideas. If something like the write-up you linked to was posted somewhere, it would probably be good to link to it in the release announcements, but I don’t know where would be the best place (for general visibility) to post such an article.

Maybe it would be worth surveying projects like numpy/scipy/matplotlib, and asking them what would have got their attention?

Perhaps this is a topic/guide that could live at https://packaging.python.org/?

3 Likes

In similar spirit I started a discussion about building conda(-forge) packages for Python 3.10 before the final release: Start Python 3.10 migration with the release candidate · Issue #1499 · conda-forge/conda-forge.github.io · GitHub This would enable the same experience for conda users as for wheel users on release.

2 Likes

cibuildwheel builds 3.10 wheels as a default since 3.10.0rc1 availability: Release v2.1.1 · pypa/cibuildwheel · GitHub

2 Likes

Currently, scipy is blocked on MacPython/scipy-wheels, which is blocked on MacPython/numpy-wheels, which seems blocked on Azure adding Python 3.10 (for Windows and Mac).
I don’t think I can help here much, but maybe one of the other people in this topic have a better idea how to help them move forward.

In my experience, putting up a single canonical webpage with clear authoritative info on the topic is pretty helpful – starting with a short and very-easy-to-read intro paragraph, that’s followed by a detailed tutorial/guide and then an FAQ and an email address/contact link to get further advice.

Then you have to advertise the news and link to that page, else people won’t necessarily look for it and find it; this can take anywhere from 30 minutes to weeks, depending on how crucial it is to get the word out and how much time you’re willing to spend on marginal utility. Some of the people you’re trying to reach pay attention to email newsletters, some to podcasts, some to Discords and other fora. Think about whom you’re trying to reach and what other hobby or professional groups/interests they may share – maybe in this case, for example, many of the projects you particularly want to reach are doing scientific/numerical stuff, so a bunch of of them are part of NumFOCUS or the SciPy and PyData conferences/meetups, so you can ask someone who’s in that world to forward stuff there. Or maybe there’s a cluster you’d like to reach in fintech, so you look for pre-existing interest groups there to send your link to.

Some places to start:

@smm heads-up in case any of this is useful to you as you construct more systematic playbooks for communicating out to the users of Python package distribution tools!

@encukou Apologies in advance if any of this is redundant and you knew it already. :slight_smile:

1 Like

FYI, for NumPy we’ll move over to cibuildwheel on GitHub Actions in the coming months (at least for Linux/Windows/macOS), which has new Python releases available earlier than other CI providers usually. CI availability is still the bottleneck though - the request to start building wheels early made sense, but it’s just a lot of work to get a Python install from somewhere custom instead of using the built-in support for Python versions that one normally uses for building wheels (and CI jobs in general).

True in general, and a good idea to do in addition to the “file issues about 3.10 wheels on the repos of many important projects”, but that’s not the problem here. The actual problem is that there is no good recipe/answer currently for where to get Python 3.10 in a way that is easy to integrate in the wheel-build CI machinery across TravisCI, Azure DevOps, Appveyor.