Provisional pyproject RPM macros: Dynamic BuildRequires for Python packages

[Miro Hrončok]

Hello fellow Python packagers. This is an announcement about a new set of RPM 
macros you can use to build PEP 517/518 enabled packages, that is Python 
packages that have the pyproject.toml file.

   https://www.python.org/dev/peps/pep-0517/
   https://www.python.org/dev/peps/pep-0518/
   https://snarky.ca/clarifying-pep-518/

The set of macros is designed for modern packaging with dynamic buildrequires in 
mind.
The macros are in the pyproject-rpm-macros package and you can use them like this:

     BuildRequires:  pyproject-rpm-macros

     %prep
     ...

     %generate_buildrequires
     %pyproject_buildrequires -t

     %build
     %pyproject_wheel

     %install
     %pyproject_install

     %check
     %tox

See the full documentation of the macros:
  https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/REA...

See example spec files:
  https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/master/f/tests

(These use setuptools (setup.py), flit and poetry for build backends, but you 
cannot tell that from the specfiles - BuildRequires are generated dynamically 
from upstream metadata.)

The macros are **provisional**, i.e. their API may be changed upon feedback 
received from you.
We are not (yet) interested in a general "update all the Python packages" hunt,

but rather in early adopters.

If you have questions, ask here. We'll gladly extend the docs if something is 
not clear.
If you find bugs, report them in bugzilla or here. Likewise for RFEs.

Happy hacking,
Python Maintenance

Python bindings for protobuf on RHEL/CentOS/EPEL 8

[Denis Arnaud]

Hi,

the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the protobuf
package (https://src.fedoraproject.org/rpms/protobuf).
A bug request has been created on Bugzilla (
https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as no status has
been given, I was wondering whether someone could shed some light on the
context.

Since protobuf is a RedHat core package (maintained by RedHat and therefore
not managed by Fedora/EPEL), it appears as a kind of black box from Fedora
perspective. On Fedora (Rawhide, 31), the Python (3) bindings are
generated/packaged (see for instance
https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3a662fe8b and
https://koji.fedoraproject.org/koji/rpminfo?rpmID=19440119), but for some
reason, those Python bindings are not generated by RedHat for RHEL/CentOS 8.

1. Would anyone from RedHat be able to provide some heads up on why those
Python 3 bindings are missing for Protobuf, and/or an approximate timeline
for when it would be generated?
2. Would RedHat need help with packaging protobuf on RHEL/CentOS/EPEL 8?
3. Would you recommend another way for Fedora packagers/users to get their
hands on the python3-protobuf/protobuf-python3 package? For instance,
through COPR, or some module we may have missed.

Kind regards

Denis

Python bindings for protobuf on RHEL/CentOS/EPEL 8

[Petr Viktorin]

On 2019-11-11 11:45, Denis Arnaud wrote:
>  Hi,
>  
>  the Python (3) bindings are missing on RHEL/CentOS/EPEL 8 for the 
>  protobuf package (https://src.fedoraproject.org/rpms/protobuf).
>  A bug request has been created on Bugzilla 
>  (https://bugzilla.redhat.com/show_bug.cgi?id=1765844), but as no status 
>  has been given, I was wondering whether someone could shed some light on 
>  the context.
>  
>  Since protobuf is a RedHat core package (maintained by RedHat and 
>  therefore not managed by Fedora/EPEL), it appears as a kind of black box 
>  from Fedora perspective. On Fedora (Rawhide, 31), the Python (3) 
>  bindings are generated/packaged (see for instance 
>  https://bodhi.fedoraproject.org/updates/FEDORA-2019-e3a662fe8b and 
>  https://koji.fedoraproject.org/koji/rpminfo?rpmID=19440119), but for 
>  some reason, those Python bindings are not generated by RedHat for 
>  RHEL/CentOS 8.
>  
>  1. Would anyone from RedHat be able to provide some heads up on why 
>  those Python 3 bindings are missing for Protobuf, and/or an approximate 
>  timeline for when it would be generated? 
Hi!
We just talked about this among Red Hat python-maint. (Sorry for the 
delay!) We don't have influence over this package; unfortunately we 
can't help directly.

>  2. Would RedHat need help with packaging protobuf on RHEL/CentOS/EPEL
> 8? 
At this level "Red Hat" is not a single entity. You're probably not 
reaching the right people on this list.
If the packager isn't active in Fedora or on Bugzilla, then 
unfortunately, the way to get them to respond is to file a customer 
support ticket.
Another way to approach this is change EPEL rules somehow to make it 
possible to build subpackages like this. From what I understand, it's 
being discussed, but it'll take time to get sorted out.

>  3. Would you recommend another way for Fedora packagers/users to get
>
>  their hands on the python3-protobuf/protobuf-python3 package? For 
>  instance, through COPR, or some module we may have missed. 
Building a replacement protobuf package in COPR is the best short-term 
solution.

Sorry I couldn't be more helpful.