gh-129712: Document the wheels tags corresponding to each universal SDK. #130389
Conversation
freakboy3742
requested review from
erlend-aasland and
corona10
as code owners
freakboy3742
added
needs backport to 3.12
| * ``intel`` (i386 and x86-64; supports ``intel`` wheels); | ||
| * ``intel-32`` (i386; supports ``i386`` wheels); | ||
| * ``intel-64`` (x86-64; supports ``x86_64`` wheels); | ||
| * ``all`` (PPC, i386, PPC64 and x86-64; supports ``universal`` wheels). | ||
|
|
There was a problem hiding this comment.
[edited] I think the terminology is misleading here. For example, supports to me implies that a universal2 build could only make use of universal2 wheels but that's not the case: it potentially supports wheels with universal2 or arm64 or x86_64 or, for completeness sake, intel or universal or fat3 or fat64 tags depending on the running arch. Likewise, for many of the other configure options. The minimum requirement for a compatible wheel is (or should be) that the architecture that the interpreter is running in is included in the set of binaries included in the wheel (there are other requirements regarding deployment targets etc). There isn't a one-to-one match. Perhaps this configure doc isn't the place to try to discuss this. Note that this section has a link at its beginning to the Mac/README.rst file which does go into some more detail about universal builds and these configure options. Perhaps something can be added there about wheels, if nothing else include a link to (what I believe to be) the canonical description of the wheel tag values in the Python Packaging User Guide. Opinions?
There was a problem hiding this comment.
Ah - I completely missed the reference to the Mac README. That definitely fills in a lot of gaps.
I think there's still room to clarify what fat3 actually means in this location (rather than leaving it to the reader to work out that it's defined in the README); and both locations would benefit from highlighting that the configuration value used for --with-universal-archs doesn't match the platform tag. I've pushed an update that (hopefully) addresses this concern.
|
Thanks @freakboy3742 for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13. |
…rsal SDK. (pythonGH-130389) Document the architectures supported by macOS universal SDK configuration flags, and add details on wheel tag naming. (cherry picked from commit 474c388) Co-authored-by: Russell Keith-Magee <[email protected]>
|
GH-130449 is a backport of this pull request to the 3.13 branch. |
…rsal SDK. (pythonGH-130389) Document the architectures supported by macOS universal SDK configuration flags, and add details on wheel tag naming. (cherry picked from commit 474c388) Co-authored-by: Russell Keith-Magee <[email protected]>
|
GH-130450 is a backport of this pull request to the 3.12 branch. |
…ersal SDK. (GH-130389) (#130449) Document the architectures supported by macOS universal SDK configuration flags, and add details on wheel tag naming. (cherry picked from commit 474c388) Co-authored-by: Russell Keith-Magee <[email protected]>
…ersal SDK. (GH-130389) (#130450) Document the architectures supported by macOS universal SDK configuration flags, and add details on wheel tag naming. (cherry picked from commit 474c388) Co-authored-by: Russell Keith-Magee <[email protected]>
In the process of getting iOS and Android wheel tags accepted into PyPI, I noticed that there isn't a 1-1 correlation between the
--with-universal-archsflag passed to./configure, and the wheel tags supported by the builds produced when that flag is used.Most of these options are for entirely historical benefit - there's very little practical use for any value other than
universal2. PPC64 hardware hasn't been available since 2006, and support for 32 bit Intel machines was dropped in 2011. However, the other values exist, and the inconsistency between the configuration value and wheel tag isn't documented anywhere. Until such time as these options are removed, we should at least document them.📚 Documentation preview 📚: https://cpython-previews--130389.org.readthedocs.build/