When we invented the %pyproject_buildrequires BuildRequires generator, it
generated build-dependencies. Imediatelly we realized that for several reasons,
also generating the runtime dependencies as BuildRequires is needed:
- they are needed to run the test suite
- they are needed to run an import check
- they make the build fail when runtime dependencies are not found
Hence, %pyproject_buildrequires -r was introduced. This flag is implied by
other flags (-x, -t, -e) but it is not a default behavior.
However, as I've done a fair amount of new package reviews and pull request
reviews to convert packages to pyproject-rpm-macros, I've noticed packagers
have a tendency to forgot the -r flag when:
1) The currently packaged version has no runtime dependencies.
This is currently quite harmless, as when the package is updated with new
dependencies, the packager will notice and add the flag. However, if we ever
have some automation for updates, we better have forward-compatible specfiles.
2) The runtime dependencies are pulled in as transitive dependencies of
manually BuildRequired packages.
For example, if there is `BuildRequires: python3-pytest` and the package
runtime-requires toml, the tests will suceed with pytest 6 (requires toml) but
will error with pytest 7 (as it migrated from toml to tomli).
3) There is not a single check run in %check.
While technically forbidden by the new guidelines, this is not enforced and
hence packages use %pyproject_buildrequires but don't run any tests. This can
result in packages that are updated into an uninstallbale state. I'd rather the
build failed in that case.
Hence, I propose we make the -r flag the default. In case some package needs to
opt-out for legitimate reasons, a new flag would exist to disable it (most
While technically a backwards-incompatible change, I belive the negative impact
should be minimal -- at worst packages that fail to install will now also fail
to build (which is a good thing IMHO).
On 09. 01. 22 19:39, Christian Heimes wrote:
> I would like to remind everybody that Python's support for OpenSSL 3.0 is
> preliminary . Python compiles with OpenSSL 3.0.0 and simple code kinda
> works. However there are known performance regressions, missing features (e.g.
> usedforsecurity flag), and potential bugs cause by API incompatibilities.
> Due to the experimental state I advise against using Python with OpenSSL 3.0 in
> It may take a while until Python gains full support for the next version of
> OpenSSL. I have shifted my personal OSS time to more fun topics like
> performance and WASM. My work time is currently limited, too.
Do you think we should switch Python in Fedora 36 to OpenSSL 1.1.1? Python was
naturally rebuilt with OpenSSL 3.0 when the distro upgraded OpenSSL. But the
older version is still available.
Note that Fedora 36 is also "preliminary" so we still have time to make this
decision until +- the beta freeze/release (end of February, early March this year).
PyPy3.8 is now available in Fedora.
On rawhide, when you dnf install pypy3, or when you run the pypy3 command, you
will get PyPy3.8. PyPy3.7 is still available for the time being (pypy3.7
package and command).
On Fedora 35, when you dnf install pypy3, or when you run the pypy3 command,
you will still get PyPy3.7. pypy3.8 package will be available from updates
testing when the build finishes and I'll create the bodhi update.
On Fedora 34, when you dnf install pypy3, or when you run the pypy3 command,
you will still get PyPy3.6. pypy3.8 package will be available in updates
testing soon: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8e29bfb393
Hello, does anybody want to take this? If not, I will.
-------- Forwarded Message --------
Subject: Python SIG at Fedora Council Video Meeting
Date: Thu, 6 Jan 2022 16:06:17 -0500
From: Tom Callaway <spotrh(a)gmail.com>
To: Miro Hrončok <mhroncok(a)redhat.com>
Miro, I know you're in the Python SIG, please forward this on as needed.
The Fedora Council would like to invite your SIG to present at an upcoming
Fedora Council video meeting. If you're interested, what we'd be looking for
from you is:
* Someone to present (on camera in a virtual meeting room) a 10-15 minute
presentation (with slides) on the state of your SIG (past, present, future)
along with any calls to action that you might have.
* Stick around for 15+ minutes for Q&A discussion
These meetings are recorded and then shared on
A small FAQ:
Q. When are these meetings held?
A. The video meetings are held monthly, on a Thursday, between 1800 - 1900 UTC.
Q. Do we have to do this?
A. No. It is an opportunity we're making available to you, but if you don't
want to (or cannot), feel free to decline (or ignore this email).
Q. Would the meeting be all about our SIG?
A. We also use some time to discuss council business, but you'd be the guest(s)
Q. Okay, we're in. How do I sign-up?
A. You reply to this email and say "Our SIG would love to do this!" and I'll
get you scheduled.
Q. I have other questions, who can I ask?
A. You can ask me! You now have my email, or you can find me any of the other
obvious places I have presence on the internet and ask me there.
Tom "spot" Callaway, on behalf of the Fedora Council