Document pecularities about spec tag parsing

[praiskup]

Description

We had some hiccups with using specfile initially: https://github.com/fedora-copr/copr/issues/2848 -> There are several types of tag resolution "expanded", "expanded with RPM", "unexpanded", some values can be defined multiple times in one spec file. It would be nice to have this properly documented.

Also, while using the library, we actually created a wrapper around python-specfile :-) and it might be worth having it here upstream, not sure. The wrapper is here: https://github.com/fedora-copr/copr/blob/7712cb4c11d9b01e41b65999030a41948bfefe5b/rpmbuild/copr_rpmbuild/helpers.py#L388-L442

cc @frostyx @lachmanfrantisek discussed today on CPT mtg

Benefit

No response

Importance

No response

Workaround

• [ ] There is an existing workaround that can be used until this feature is implemented.

Participation

• [ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)

[FrostyX]

we actually created a wrapper around python-specfile :-) and it might be worth having it here upstream, not sure.

The wrapper is trying to simplify the usage of python-specfile in our codebase for our specific use case. So I am not sure how useful it would be for you and how much work it would be to cover all attributes.

Anyway, it workarounds some insufficiencies for us:

• Not all attributes are easily accessible via specfile.Specfile. For example it is possible to do spec.name or spec.version but not for example spec.excludearch, spec.exclusivearch, and probably many others.
• This magic combo of tags = spec.tags(spec.parsed_sections.package).content and tags.foo.expanded_value is IMHO too low-level. As a user, I simply want spec.foo or worst case scenario spec.tags.foo.
• We don't want everything to be a string. It is known what data types tags are, so we want epoch to be an integer, exclusivearch to be a list of strings, etc.

Any steps towards fixing these issues in python-specfile would be appreciated. It doesn't matter to us if it would be based on our wrapper or a completely different solution.

PS: Don't get me wrong, the python-specfile is awesome and does exactly what we want from it. Only the API would deserve polishing a little.

[nforro]

The thing is, specfile is focused on modification, that's the reason for all the "shortcomings" (except for the first point, that could probably be solved). A read-only/everything-expanded API just isn't there. Is there actually a reason for you to use specfile rather than e.g. import rpm; rpm.spec("some.spec").sourceHeader.epoch? I don't want to discourage you from using specfile, I'm just wondering if it even makes sense to implement such an API. You can also already use spec = Specfile("some.spec"); spec.rpm_spec.sourceHeader.epoch to take advantage of the parsing hacks and high-level macro access that specfile provides.

[mfocko]

Still relevant.