Am 30.01.22 um 00:28 schrieb Matěj Cepl:
Dne 29. 01. 22 v 17:26 Ben Greiner napsal(a):
python38-Sphinx does not provide the pkg_resources style __init__.py file from python-Sphinx (anymore?), but all the python-sphinxcontrib-* packages expect it. The PYPI packages all provide it and overwrite each other during install, but we can't allow those file conflicts in a rpm package.
So either python-Sphinx needs to reintroduce this file or there needs to be a python-sphinxcontrib package providing it, which all python-sphinxcontrib-* packages depend on. I didn't check. Maybe it exists and is just not in the dependency tree?
AFAICT Tumbleweed did have the pkg_resources-style __init__.py file and later outsourced it into a meta python-sphinxcontrib package [1]. SLE/Leap 15 still does have that one. Somehow it was dropped from TW at one point.
Couldn't we charge ahead and switch everything to PEP-420 native namespace packages? They should be supported natively since Python 3.3, that's on any platform SUSE provides (all the way down to SLE-11 if you ignore Python 2 ;)).
I guess it is possible for Tumbleweed. Some cons to consider: * You are deviating from the upstream design. * You have to fix every single sphinxcontrib-* package like [2], in contrast to one easy fix in python-Sphinx.spec * In SLE/Leap, there is still the python-sphinxcontrib package interfering. * If a user mixes system the sitelib with a user-sitelib or virtualenv sitelib and installs PyPI packages the whole design fails in the same way as Seb's examples fail with the custom PYTHONPATH [3]: "*Every*distribution that uses the namespace package must include an identical|__init__.py|. If any distribution does not, it will cause the namespace logic to fail and the other sub-packages will not be importable."
Best,
Matěj
- Ben [1] https://build.opensuse.org/request/show/527167 [2] https://build.opensuse.org/package/rdiff/home:bnavigator:branches:devel:languages:python/python-sphinxcontrib-asyncio?opackage=python-sphinxcontrib-asyncio&oproject=devel%3Alanguages%3Apython&rev=4 [3] https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...