I would like some advice on this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2036438
There are a number of packages with names of the form python-sphinxcontrib-foo, which install their files into %{python3_sitelib}/sphinxcontrib/foo/. The issue is that at least two of these, python-sphinxcontrib-asyncio and python-sphinxcontrib-zopeext, install a file named %{python3_sitelib}/sphinxcontrib/__init__.py, and the files are not identical.
Any thoughts on how this should be dealt with are welcome. I suggested in the bug that we could introduce a package named simply python-sphinxcontrib that owns both the sphinxcontrib directory and the __init__.py file. The other python-sphinxcontrib-* packages would depend on it, and would not install any such __init__.py file. There is no such upstream package; this would be a Fedora construct simply to deal with the file collision. Perhaps we could even make that a subpackage of python-sphinx.
Other ideas are welcome, especially if they mean less work for me. :-)
On Tue, 4 Jan 2022 at 23:04, Jerry James loganjerry@gmail.com wrote:
I would like some advice on this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2036438
There are a number of packages with names of the form python-sphinxcontrib-foo, which install their files into %{python3_sitelib}/sphinxcontrib/foo/. The issue is that at least two of these, python-sphinxcontrib-asyncio and python-sphinxcontrib-zopeext, install a file named %{python3_sitelib}/sphinxcontrib/__init__.py, and the files are not identical.
I think these packages are wrong upstream. The `sphinxcontrib` directory is provided by python3-sphinx, and it specifically doesn't have `__init__.py` there. Those extensions should not be adding one, so as to keep the implicit namespace package nature of that directory: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...
By the contents of the files, it appears they are trying to force it to be a pkg_resources-style namespace package: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...
But since Sphinx didn't do that in the first place, there's no guarantee that other packages will contain `__init__.py` (and indeed most do not).
Any thoughts on how this should be dealt with are welcome. I suggested in the bug that we could introduce a package named simply python-sphinxcontrib that owns both the sphinxcontrib directory and the __init__.py file. The other python-sphinxcontrib-* packages would depend on it, and would not install any such __init__.py file. There is no such upstream package; this would be a Fedora construct simply to deal with the file collision. Perhaps we could even make that a subpackage of python-sphinx.
Other ideas are welcome, especially if they mean less work for me. :-)
Jerry James http://www.jamezone.org/
On Tue, Jan 4, 2022 at 11:59 PM Elliott Sales de Andrade quantum.analyst@gmail.com wrote:
I think these packages are wrong upstream. The `sphinxcontrib` directory is provided by python3-sphinx, and it specifically doesn't have `__init__.py` there. Those extensions should not be adding one, so as to keep the implicit namespace package nature of that directory: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...
By the contents of the files, it appears they are trying to force it to be a pkg_resources-style namespace package: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...
But since Sphinx didn't do that in the first place, there's no guarantee that other packages will contain `__init__.py` (and indeed most do not).
Thank you, Elliott. That's good information. I will talk to the respective upstreams about this.
Regards,
On 05. 01. 22 17:38, Jerry James wrote:
On Tue, Jan 4, 2022 at 11:59 PM Elliott Sales de Andrade quantum.analyst@gmail.com wrote:
I think these packages are wrong upstream. The `sphinxcontrib` directory is provided by python3-sphinx, and it specifically doesn't have `__init__.py` there. Those extensions should not be adding one, so as to keep the implicit namespace package nature of that directory: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...
By the contents of the files, it appears they are trying to force it to be a pkg_resources-style namespace package: https://packaging.python.org/en/latest/guides/packaging-namespace-packages/#...
But since Sphinx didn't do that in the first place, there's no guarantee that other packages will contain `__init__.py` (and indeed most do not).
Thank you, Elliott. That's good information. I will talk to the respective upstreams about this.
For more context about Python namesapace packages, I recommend this thread (particularly Toshio's reply):
https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
As for the `sphinxcontrib` directory provided by python3-sphinx - note that this is done downstream.