-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Avoid exporting incorrect PyInit_*
symbols (backport #12889)
#12893
Conversation
Cherry-pick of 120b73d has failed:
To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the following people are relevant to this code:
|
Using the `#[pymodule]` derive macro in PyO3 0.21 always causes a `PyInit_*` symbol with a matching name to be exported in the output `cdylib`. This is required for the top-level module, in order for Python to import it---it needs to know which symbol in a shared library file it should call---but submodules must be manually initialised, so do not need it. Including it is typically harmless (and something we've been doing for a long time), but it is technically against the coding rules for CPython extensions[^1]. Recent versions of `abi3audit` (0.0.11+) have tightened their symbol checkers to better match the CPython guidelines, which causes our wheels to be rejected by their audits. This is, in theory, not a break of abi3 because CPython could never introduce an API-elvel `PyInit_*` function themselves without causing problems, so there ought to be no problems for our users, even with future Python versions. That said, we still want to pass the audit, because the coding guidelines are useful. This commit is not the cleanest way of doing things. PyO3 0.22 includes a `#[pymodule(submodule)]` option on the attribute macro, which lets us use all the standard code generation while suppressing the unnecessary `PyInit_*` symbol. When we are ready to move to PyO3 0.22, we probably want to revert this commit to switch to that form. [^1]: https://docs.python.org/3/c-api/intro.html (cherry picked from commit 120b73d)
818c785
to
266ed8f
Compare
Pull Request Test Coverage Report for Build 10218833747Details
💛 - Coveralls |
Summary
Using the
#[pymodule]
derive macro in PyO3 0.21 always causes aPyInit_*
symbol with a matching name to be exported in the outputcdylib
. This is required for the top-level module, in order for Python to import it---it needs to know which symbol in a shared library file it should call---but submodules must be manually initialised, so do not need it. Including it is typically harmless (and something we've been doing for a long time), but it is technically against the coding rules for CPython extensions1.Recent versions of
abi3audit
(0.0.11+) have tightened their symbol checkers to better match the CPython guidelines, which causes our wheels to be rejected by their audits. This is, in theory, not a break of abi3 because CPython could never introduce an API-elvelPyInit_*
function themselves without causing problems, so there ought to be no problems for our users, even with future Python versions. That said, we still want to pass the audit, because the coding guidelines are useful.This commit is not the cleanest way of doing things. PyO3 0.22 includes a
#[pymodule(submodule)]
option on the attribute macro, which lets us use all the standard code generation while suppressing the unnecessaryPyInit_*
symbol. When we are ready to move to PyO3 0.22, we probably want to revert this commit to switch to that form.Details and comments
We found this during the deployment of 1.2.0rc1, since that's the most recent PyPI release since
abi3audit
released version 0.0.11. This commit creates a wheel that passes the audit at its current version 0.0.14.This is an automatic backport of pull request #12889 done by Mergify.
Footnotes
https://docs.python.org/3/c-api/intro.html ↩