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.
The set of macros is designed for modern packaging with dynamic buildrequires in
The macros are in the pyproject-rpm-macros package and you can use them like this:
See the full documentation of the macros:
See example spec files:
(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
If you find bugs, report them in bugzilla or here. Likewise for RFEs.
On 29. 11. 19 2:53, Conrad Sand wrote:
> Hi Miro,
> Please _do not_ remove arpack and arpack-devel.
Sure, please rebuilt it. Orion has started to work on it in
> A lot of other packages depend on that.
At least 49 according to the report, yes. That's why I have sent it out, so the
dependent package maintainers have a chance to fix it.
> Removing arpack doesn't make any sense.
Removing packages that haven't been built for certain number of releases is a
Fedora policy described in:
It is not my personal quirk.
If you don't agree with the policy itself, I suggest you start having a serious
discussion about the policy on devel mailing list (CCed). Last time I tried to
discuss the policy on the list in this thread:
My intent was to make the policy less strict and give packagers some room.
If the intent was not accomplished enough, I am still open to hear more suggestions.
If you don't disagree with the policy but thing that it should not apply to
arpack, please, discuss that to. Simply saying "removing arpack doesn't make any
sense" without providing all the necessary context is not helpful.
> If you remove arpack, you might as well remove all serious scientific
> software from Fedora.
I don't understand this statement. If we remove arpack we might as well remove
the 49 packages. That hardly all serious scientific software in Fedora.
I realize that there are some high impact packages. That's why we should
together strive to fix the build failure and avoid disruption.
> Rather than providing the sole reason for the removal as "fail to
> build from source", shouldn't the first effort be towards fixing the
> affected package? You break it, you fix it, no?
My effort is to raise the awareness about he failure. Despite my large effort, I
cannot possibly fix all the build failures in Fedora. If I broke arpack, I am
terribly sorry, but I am not aware of that.
The failure is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=1734942
Yet there was no movement until this e-mail. In a way, the e-mail helped.
> Throwing out arpack is an absolute overkill, and to be perfectly
> honest, a boneheaded and extremely shortsighted proposal.
My intentions are to raise the awareness of the issue. Throwing anything away
will only happen to packages where nobody cares about them. Clearly, you care
about arpack and that is appreciated.
There are 2+ months now to do one of the following:
- make it build
- change the policy
- exempt arpack from the policy
I can help with the second two, if there are good reasons given and rest of the
contributors agree. Orion is helping with the first.