Hello Pythonistas and Rustaceans,
TL;DR: Only PyO3 v0.19.2 (and later) will ever properly support Python
3.12. Port your Python projects to v0.19 **NOW**.
Older versions of PyO3 (especially pyo3 v0.15, v0.16, v0.17, and
v0.18) are *not* compatible with Python 3.12 due to some ABI changes
in unicode strings and behavioural changes wrt/ "immortal" objects.
This also affects all current versions of the "cpython" Rust bindings,
with no timeline for Python 3.12 support.
As far as I can tell, extensions that use pyo3 < v0.19 or the
"cpython" bindings can (and likely will) not work as expected on
Python 3.12 if they use the affected APIs (either by producing garbage
data in strings that are passed over the FFI boundary, or by
There are applications in Fedora that still rely on *ancient* versions
of PyO3, potentially affected by this:
- cpython: mercurial
- pyo3 v0.15: fapolicy-analyzer, python-bcrypt, python-cryptography
- pyo3 v0.16: python-y-py
- pyo3 v0.17: unused compat packages, will be retired
- pyo3 v0.18: matrix-synapse
I *stongly* recommend to move all of these packages to pyo3 v0.19 in
Rawhide as soon as possible. I will try to submit pull requests with
the required changes for affected packages (except mercurial, since
there's no version of the "cpython" crate that supports Python 3.12 in
There's already a few packages that depend on pyo3 v0.19, which I will
rebuild in rawhide for pyo3 v0.19.2, which has much better support for
Python 3.12 than v0.19.0 and v0.19.1 (breezy, python-rpds-py, orjson)
unless there are any objections.
As soon as no packages depend on the compat packages for old versions
of pyo3 any longer, I will retire them from Rawhide (and F39,
depending on the timing), since they will never work with Python 3.12
and nothing should use them.
I've added <package>-maintainers(a)fedoraproject.org for all these
packages to the CC of this message.
Rust SIG / PyO3 maintainer in Fedora
%pyproject_save_files automatically handles marking license files
with %license when a build backend installs them into a package's
dist-info directory and the License-File header is specified in the
METADATA file. Currently, only setuptools and hatchling meet this
criteria. Notably, poetry and flit do not support this. They will
install license texts into the dist-info directory, but they do not add
the License-File metadata. The License-File tag is not standardized, and
discussion on PEP 639 which defines this standard has stalled. I believe
relying on this feature is a problem, as if a project changes build
systems or some other config and a packager doesn't realize, suddenly
the license file won't be marked with %license or even worse, not
installed at all. Since the pyproject macros read the build backend from
pyproject.toml without packagers having to manually specify anything
(which is generally great!), this situation seems likely to occur.
Until these issues are resolved, I propose banning this in Fedora and
requiring packagers to manually mark files with %license or at least
adding a large warning to the Packaging Guidelines. It can be similar to
the `'*' +auto` flags which are used by pyp2spec for automatic PyPI
builds in Copr but not allowed in Fedora proper.
What do y'all think? Am I missing something?
Maxwell G (@gotmax23)
python-calcephpy builds were FTB since between the F39 mass rebuild (which completed fine) and the Cython 3.x change (which started to fail).
While I was waiting for upstream to fix the package for compatibility with Cython 3.x I tried to rebuild it forcing cython < 3.0, but I got an odd build failure to which I didn't pay great attention, I simply thought about some glitch trying to force the cython version to the compat package.
Now that upstream released a new version compatible with Cython 3.x I tried to update the package, but I still get the odd build failure. It seems that during the configure script the package complains about being cross-built... the latest build attempt completed fine on i686 and ppc64le, while failed on other architectures.
Does anyone have any idea about this?
First, is it possible to use this macro if the pyproject.toml isn't in the
root directory of the package? There doesn't seem to be an option to
specify a path, so I tried cd'ing into a path and running it, but it
seemed to run into an odd error like it was trying to include my directory
as a package.
Second, can %pyproject_buildrequires (and the other %pyproject_ macros) be
used multiple times in a package? I have a package that has multiple
pyproject.toml files in it (but that's mostly a legacy thing, so I could
probably separate them into multiple RPMs).