Open messense opened 1 week ago
For testing it's possible to use https://github.com/Quansight-Labs/setup-python as a drop-in replacement for the GitHub one
Happy to help with this if needed. The windows free-threaded packaging situation is "fun".
Happy to help with this if needed.
Thanks, feel free to send PR to this branch!
It looks like a few of the tests hardcode using abi3:
○ rg "abi3" **/Cargo.toml
pyo3-pure/Cargo.toml
10:pyo3 = { version = "0.22.0", features = ["abi3-py37", "extension-module", "generate-import-lib"] }
pyo3-abi3-without-version/Cargo.toml
2:name = "pyo3-abi3-without-version"
8:pyo3 = { version = "0.22.4", features = ["abi3", "extension-module"] }
11:name = "pyo3_abi3_without_version"
workspace-inverted-order/path-dep-with-root/Cargo.toml
13:pyo3 = { version = "0.22.5", features = ["abi3", "abi3-py38", "extension-module"] }
pyo3-ffi-pure/Cargo.toml
7:pyo3-ffi = { version = "0.18.1", features = ["abi3-py37", "extension-module"] }
Since free-threading and abi3 are incompatible, would it be better to skip over the tests that use these crates? For the ones that are testing whether the limited api support is working correctly I think skipping them makes sense, but some of these seem to be more generic integration tests for maturin that happen to use the limited API.
I don't see an easy way to optionally turn on and off the abi3 feature in the test crates. Am I missing something? If not, any guidance?
We should probably try to support this case because cryptography
probably hard-codes the abi3 build in the same way. It's useful to do that because then the whole system limits you to the limited API.
My gut says that it'd be good enough for now if Py_GIL_DISABLED
being set caused pyo3-build-config
to no-op the whole lot of abi3 features. So maybe there's a PyO3 fix required here? 🤔
My gut says that it'd be good enough for now if Py_GIL_DISABLED being set caused pyo3-build-config to no-op the whole lot of abi3 features. So maybe there's a PyO3 fix required here?
Hmm, that's sort of in the vein of https://github.com/PyO3/pyo3/pull/4719, but maybe what I'm doing there making more things hard errors is bad and it would be better to warn and just turn off limited API and set the ABI to Py_3_13 if someone is trying to build for the free-threaded ABI but asks for an earlier ABI.
We should probably try to support this case because
cryptography
probably hard-codes the abi3 build in the same way. It's useful to do that because then the whole system limits you to the limited API.
We have a convoluted setup where Cargo.toml
specifies the abi3
feature, pyproject.toml
specifies the pyo3/abi3-py37
feature, and then some individual wheel building jobs specify higher abi3 ABIs.
👍 It seems to me that we probably don't want cryptography
to have to remove abi3
feature from Cargo.toml
to build against the freethreaded build, so silently overriding (like we do for PyPy & Graalpy) seems more correct. I guess we can probably also make that work for the abi3-py37
too, I'll check how that works...
Yep, if I add abi3-py37
to Cargo.toml
and then try to build with PyPy, the build succeeds (with a warning about PyPy not supporting abi3), I guess we should match here.
It looks like three of the crates use old PyO3 APIs and need to be updated:
test-crates/sdist_with_target_path_dep/src/lib.rs
18: let pool = ::pyo3::GILPool::new();
116: let pool = ::pyo3::GILPool::new();
test-crates/lib_with_path_dep/src/lib.rs
18: let pool = ::pyo3::GILPool::new();
116: let pool = ::pyo3::GILPool::new();
test-crates/sdist_with_path_dep/src/lib.rs
18: let pool = ::pyo3::GILPool::new();
116: let pool = ::pyo3::GILPool::new();
Other errors from trying to build one of these crates:
I'm confused why the update to PyO3 0.23 last week didn't break tests using these crates on CI.
I'm confused why the update to PyO3 0.23 last week didn't break tests using these crates on CI.
Some of these tests are not built but only used to test generating source distribution, will fix them later in a separate PR.
Implementation details:
Py_GIL_DISABLED
build flag for runnable Python interpreterspython3.13t
when cross compilingCloses #2298 Closes #2315