Bug 2127371
| Summary: | python-pybtex fails to build docs with Pygments 2.13 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Karolina Surma <ksurma> |
| Component: | python-pybtex | Assignee: | Jerry James <loganjerry> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | loganjerry |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | python-pybtex-0.24.0-8.fc38 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-09-20 15:16:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Karolina Surma
2022-09-16 07:24:12 UTC
I think the issue is that docs/pybtex_doctools/__init__.py uses the pkg_resources way of registering entry points. I'm not sure how to fix it either, but I'll poke at it for a bit and see if I get lucky. :-) If I am reading the importlib.metadata code correctly, it is no longer possible to register entry points in code. It reads entry_points.txt every time it is asked for a list of entry points, and what you get is an exact representation of what is in that file. Right? So the only way pybtex is going to build documentation successfully is if its pygments entry points appear in entry_points.txt.
On the other hand, this is code that is only executed during documentation build. It is not installed, nor referenced when pybtex is actually used, so we don't want phantom entries to show up in the installed entry_points.txt.
That leads me to this version of %build.
```
%build
%pyproject_wheel
# Build documentation
# Cheating, hacky workaround for pygments 2.13.
# I cannot be responsible for damage to your eyes from seeing the following.
cp -p pybtex.egg-info/entry_points.txt pybtex.egg-info/entry_points.txt.orig
cat >> pybtex.egg-info/entry_points.txt << EOF
[pygments.styles]
pybtex = pybtex_doctools.pygments:PybtexStyle
[pygments.lexers]
bibtex-pybtex = pybtex_doctools.pygments:BibTeXLexer
bst-pybtex = pybtex_doctools.pygments:BSTLexer
EOF
PYTHONPATH=$PWD:%{pyproject_build_lib} make -C docs html man
rm -f docs/build/html/.buildinfo
# Undo the cheating, hacky workaround for pygments 2.13.
mv pybtex.egg-info/entry_points.txt.orig pybtex.egg-info/entry_points.txt
```
That actually works. I get good builds of the python-pybtex package with both Rawhide and your pygments 2.13 repository. Just looking at that makes me want to go wash my brain off ... but it does work.
I'm open to suggestions for a better approach.
Thank you for investigating the issue so promptly! I now understand where the problem comes from. It's tricky. We discussed this approach and looked for other possibilities with lbalhar today. It seems your way is currently the way to achieve the goal. If upstream defined entry points differently and got them to the distribution, we could grab them, but as you pointed out, having phantom entries in the installed distribution is not what we want. I guess that strictly speaking, the backup and restore of the unpacked egg-info/entry_points.txt is not necessary at this point of the build process. The wheel with the dist-info/ metadata is already stored in pyproject-wheeldir/ and the %install macros use only that built wheel to proceed, anything else is discarded. For the record, another option would be dropping the docs altogether. (In reply to Karolina Surma from comment #3) > We discussed this approach and looked for other possibilities with lbalhar > today. It seems your way is currently the way to achieve the goal. > If upstream defined entry points differently and got them to the > distribution, we could grab them, but as you pointed out, having phantom > entries in the installed distribution is not what we want. Okay, I will clean that up a little and commit. > I guess that strictly speaking, the backup and restore of the unpacked > egg-info/entry_points.txt is not necessary at this point of the build > process. > The wheel with the dist-info/ metadata is already stored in > pyproject-wheeldir/ and the %install macros use only that built wheel to > proceed, anything else is discarded. Ah, good. Okay, that simplifies things slightly. > For the record, another option would be dropping the docs altogether. Yes, but I myself frequently refer to offline documentation. I'm sure I'm not the only one who does that, so I think it is worthwhile to make a reasonable effort to produce such documentation. There comes a point where the effort is just too much, of course, but I don't think we're there yet with this package. FEDORA-2022-6d0c9bff39 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6d0c9bff39 FEDORA-2022-6d0c9bff39 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report. |