-
Notifications
You must be signed in to change notification settings - Fork 31
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
CI: Investigate why the sandbox setup croaks with Python 3.10 on macOS >= 11, with Buildout #428
Conversation
I think the root cause for the execption at the
|
Replicating what @idgserpro was recommending at pypa/setuptools#2514 (comment),
GHA shows:
|
Adding Funny enough, Python 3.10 on macOS now succeeds with SA13, but still fails with SA14. As we can clearly see from the output, it looks like the The reason is that while some packages are graceful on this and will use their non-optimized pure Python implementations, the SA14 build pulls in I am running out of ideas. There might even be something wrong with the environment provisioning operations at GHA?
Footnotes |
There is a difference between setting up a Python 3.9 1 vs. a Python 3.10 2 environment. Downgrading to 3.10.4 and 3.10.3 with c2e92d9 and a6a6c1b didn't help.
Footnotes |
On another patch, we are observing problems with Python 3.10 on macOS 11 It looks like there is no gcc compiler installed or available. Reference: crate/crate-python#428
After some further research on this matter, we
More relevant and solid details beyond initial observations and corresponding speculations can be found within those resources. |
- The sandbox setup is now based on vanilla Python and virtualenv. - A convenient bootstrap script is provided, which can be used like `source bootstrap.sh`. - The test runner has not been changed, it is still `zope.testrunner`. - The command line invocation interface `./bin/test` has not been changed. - Buildout is now only used for downloading the CrateDB tarball using `hexagonit.recipe.download`. References: - #428 - crate-workbench/test-buildout-python310#1
#429 will swiftly resolve all the matters on this. |
- The sandbox setup is now based on vanilla Python and virtualenv. - A convenient bootstrap script is provided, which can be used like `source bootstrap.sh`. - The test runner has not been changed, it is still `zope.testrunner`. - The command line invocation interface `./bin/test` has not been changed. - Buildout is now only used for downloading the CrateDB tarball using `hexagonit.recipe.download`. References: - #428 - crate-workbench/test-buildout-python310#1
- The sandbox setup is now based on vanilla Python and virtualenv. - A convenient bootstrap script is provided, which can be used like `source bootstrap.sh`. - The test runner has not been changed, it is still `zope.testrunner`. - The command line invocation interface `./bin/test` has not been changed. - Buildout is now only used for downloading the CrateDB tarball using `hexagonit.recipe.download`. References: - #428 - crate-workbench/test-buildout-python310#1
With 3e58910, we switched this to all available macOS runners in order to get the big picture. -- https://github.com/crate/crate-python/actions/runs/2533958091 |
We have been continuing corresponding investigations and discussions at crate-workbench/test-buildout-python310#1 ff. |
#429 removed significant portions of the Buildout-based setup and resolved the issue already. Closing this. |
Edit: The outcome from this investigation has been converged into an upstream bug report at buildout/buildout#609. It will be kept alive for further ramblings. Do not merge!
At #426 and #427, we found GHA croaks when running
buildout
with Python 3.10 on macOS. See, for example, https://github.com/crate/crate-python/runs/6935572867.P.S.: The nightly run did not catch it because it only runs
ubuntu-latest
- why?