Ownership of sphinxcontrib/__init__.py

[jamesjer]

Starting with version 0.3.0, this project installs a file to the parent namespace, sphinxcontrib/__init__.py. In Fedora, this has caused a problem for us, because sphinxcontrib-asyncio does likewise, and the two files differ. I brought this up on the Fedora developer's mailing list, and Elliott Sales de Andrade has this to say:

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/#native-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/#pkg-resources-style-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).

Does sphinxcontrib-zopeext need that __init__.py file for some reason? I tried removing it, and was still able to build the ZODB documentation.

[jamesjer]

Here is the same issue reported to sphinxcontrib-asyncio: aio-libs/sphinxcontrib-asyncio#12

[mforbes]

I see the potential issue and indeed, all the tests pass, so I will commit 0.3.2 without this file. I want to think through the logic a bit more before closing this to see if there is a potential problem.

[mforbes]

I think deleting the __init__.py from the namespace package is the right thing to do. Feel free to reopen if there are any further issues.

• PEP 420
• Native namespace packages
• support namespace packing python-poetry/poetry#167 (comment)