-
Notifications
You must be signed in to change notification settings - Fork 6
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
Test failures on GHA macos runners #181
Comments
Apparently the upgrade to macOS Sonoma broke
|
Followup to my previous comment and probably of interest to @icemac: The culprit is how broken buildout/setuptools/distutils/pkg_resources is when it comes to naming binary eggs. The name contains information about the system platform, like These live vs. cached lookups are not done consistently. This will cause problems when the OS is upgraded. During the conversion from wheel to egg buildout will believe there's already an egg at Workaround: Major macOS upgrades require re-building all self-compiled Python interpreters to fix the mismatch of cached versus real system information. |
The
macos
GitHub Actions runners reveal several issues. Tests using Python 3.11 on bothmacos-12
andmacos-11
runners as well as tests using Python 3.9 and 3.10 onmacos-12
runners fail during the buildout run's dependency installation step. The binary wheel forzope.interface
is typically the first such package encountered, it is downloaded and then fails to install with a traceback similar to the one shown at the bottom.These issues do not show up on any local macOS install with either a self-compiled Python or
homebrew
-installed Python that will by default compile to the specific machine architecture (arm64
orx86_64
). Later Python versions on the GHA runners, however, are compiled asuniversal2
, which combines both architectures in "fat" binaries, using theconfigure
flags--enable-universalsdk --with-universal-archs=universal2
.It seems neither
zc.buildout
norsetuptools
deal with this correctly, and how we usesetuptools
withsetup_requires
to build binary packages that depend on other binary packages appears to be an issue as well.zc.buildout
uses a completely unsuitable simplistic way to pick a package from a list of candidates returned from the PyPI index, see Problem with Buildout on Python 3.10 and macOS >= 11; with reproduction repository buildout/buildout#609 (comment). This algorithm cannot deal with situations where more than a single binary wheel is returned from PyPI, as would be the case when a wheel exists for the specific archtitecture plus auniversal2
wheel.setuptools
appears to misinterpret the macOS version number baked into the wheel name, see Question aboutpkg_resources.compatible_platforms
on macOS pypa/setuptools#3687Some of this was already discussed in zopefoundation/Zope#1071. I want to take this up again soon and hopefully find some solution.
The text was updated successfully, but these errors were encountered: