On 19. 12. 21 20:26, Matthew Miller wrote:
On Sun, Dec 19, 2021 at 12:14:29PM +0100, Miro Hrončok wrote:
On 17. 12. 21 17:58, Matthew Miller wrote:
The modern Python macros are ... kind of a lot to pick up as a casual
packager
If you could share a more constructive feedback, I'd gladly iterate
on the documentation or the macros themselves.
I guess I mostly meant that literally: it's a lot! I started using pyp2rpm,
which says
Convert Python packages to RPM SPECFILES. The packages can be downloaded
from PyPI and the produced SPEC is in line with Fedora Packaging
Guidelines or Mageia Python Policy.
... which was probably my first mistake, because that uses a previous
generation, and I should know better than to trust that random package
descriptions are current. :)
OK, let me try to correct that:
https://src.fedoraproject.org/rpms/pyp2rpm/pull-request/2
But there are plenty of other tools that you can use to generate a wrong
specfile. It is hard to keep them up to date -- e.g. rpmdevtools maintains
compatibility with other distros without our macros.
I should have just thrown all of that out and gone with the template
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_empty_spec_file
Yes, that's why the empty spec file exists in the first place, so packagers can
copy and adapt.
On that template in specific:
1. It's not immediately clear that "..." means "put package name here".
Oh. See, to me this was rather obvious. What do you actually expected it meant?
Do you have an idea how to make it more clear?
2. You mentioned in the review request — and Zbyszek said something similar
— that it'd be better to repeat the package name throughout the spec
file in the various place it's needed. That doesn't feel right to me.
I know the macros replace a lot of boilerplate, which is a good direction,
but having the name be different in every file _throughout_ the file makes
it harder to pick up when something is different from standard. It seems
that a lot of python packages could be identical _except_ for the header.
(And maybe then all of that eventually hidden completely with just some
thing near the top that indicates "standard python package".)
As does Zbyszek, I think this is a common misconception. It seems that
packagers assume that if they define %pypi_name, the spec file is somewhat more
universal. It kinda makes sense, I used to do it as well.
Except suddenly, you also need to define %github_name, which happens to have a
different case. And %module_name, because the imported module does not contain
the py prefix. Or there are multiple modules shipped in this package.... and so
on. And as soon as you start defining 2, 3, ... more different macros to mean
"some kind of name", the spec file turns out to be much less readable and less
universal.
In reality, I have not seen many identical Python packages except for the
header that were simple or readable.
It's much easier to search for the name(s) and replace them once, if you are
into cop-pasting existing spec files into new packages, rather than the need to
do it over and over again in your head.
This idea that packagers could copy one specfile and change header to make it
another package is also one reason why packagers keep adding stuff that has not
been necessary for years.
3. The machinery to make every package be python-... while generating an
actual python3-... subpackage is awkward. Are we stuck with that forever?
We are stuck with it for now.
Overall in the guideline doc, back to the "it's a lot!" feeling...
I guess that's because they were written as guidelines and not as a tutorial.
Writing a tutorial and having that in the preamble of the guidelines is actuall
an idea that has been lurking in my head for a while.
What do you think about having a "Quick Version" at the top, which includes
the spec file template, followed by a line-by line commentary — or at least,
section by section. Like this:
Name: python-...
Version: ...
Release: 0%{?dist}
Summary: ...
Packages primarily providing a python library must have names starting
with `python-` and that should be followed by the name of the main
importable module. Applications which happen to be written in Python
should follow the standard Fedora guidelines. See [Naming] for details
Version, Release, and Summary are as standard for Fedora packages.
License: ...
URL: https://...
Source0: %{url}/archive/v%{version}/...-%{version}.tar.gz /
%{pypi_source ...}
These are also as normal, but also see [Source files from PyPI].
BuildArch: noarch
BuildRequires: gcc
Pick **one** of the above, depending on the package. (Note on the
generate-buildrequires macro here. Will that work for archful devel
package requirements?)
I am not sure I understand this question. You can use the
%pyproject_buildrequires macro with archful packages, but it will only generate
requirements on other Python packages(setuptools, Cython, etc.). If your
package needs libmagic-devel to build, you still need to BuildRequire that one
manually.
BuildRequires: python3-devel
This is mandatory for every package that uses Python at runtime.
... and so on.
Let's do that. I've put that on my TODO.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
