Buster isn't available for anymore for Python 312 so we have to update.
This also updates to Python 3.11.7, which turns out to be relatively invasive. I broadly
xfailed failing tests in `python_tests.yaml` since we'll upgrade to Python 3.12 soon anyways.
One of the cpython tests (test_plistlib.TestBinaryPlistlib.test_deep_nesting)
seems to be extremely sensitive to stack utilization and stack overflows in our
CI when even a tiny amount of extra stack is used. I doubt this is a problem in
real life -- I certainly cannot reproduce it outside of the CI service. But this
rearranges the code to avoid any additional stack usage so that CI will pass.
One of the cpython tests (test_plistlib.TestBinaryPlistlib.test_deep_nesting)
seems to be extremely sensitive to stack utilization and stack overflows in our
CI when even a tiny amount of extra stack is used. I doubt this is a problem in
real life -- I certainly cannot reproduce it outside of the CI service. But this
rearranges the code to avoid any additional stack usage so that CI will pass.
@ryanking13 added these very nice error messages to the `ModuleNotFound`
errors. However they introduce a few problems:
1. `find_spec` is supposed to return `None` or a spec and not to raise an error.
If it raises errors, it can cause trouble in code that tries to check if a module is
installed or not.
2. Other code that tries to add new import hooks has to know to insert them
before these error-raising import hooks.
See the discussion in #3262.
This instead patches `importlib._bootstrap` to create a function called
`_get_module_not_found_error`. We then can monkey patch this to modify
the error messages that `importlib` raises.
See Python issue: https://github.com/python/cpython/issues/100208
The command line runner in #2976 finally works, but it is a large change set so
I am planning to split it up. This is the first PR split off from there.
This PR adds a patch to Python to expose pymain_run_python. We cannot use the
public API Py_RunMain for this purpose because it finalizes the Python
interpreter with Py_FinalizeEx when it is done. If we start an async task with
Py_RunMain then it will segfault. pymain_run_python does a large amount of work
and reproducing it is undesirable.
I added an args parameter which accepts command line arguments. The private
entry point pyodide._main._run_main() executes the main Python entrypoint
without shutting down the interpreter and returns the return code.
All libffi tests pass now. The only failing ctypes test is test_callback_too_many_args which doesn't segfault anymore, it only soft fails. Planning to submit a PR to cpython that fixes test_callback_too_many_args.
See also:
bugs.python.org/issue47208
https://github.com/emscripten-core/emscripten/pull/16658
* Patch ceval to add interrupt handler callback
* Don't use SharedArrayBuffer in test, Firefox doesn't expose it
* Fix test
* Retest
Co-authored-by: Jan Max Meyer <jmm@phorward.de>
When sqlite was originally added, the issue
described was bypassed by patching the python files. An alternative
workaround is used here that doesn't require any patching.
Hood Chatham