The setuptools documentation is very explicit about adding code to __init__.py files from namespaces:
You must NOT include any other code and data in a namespace package's
__init__.py. Even though it may appear to work during development, or when projects are installed as .egg files, it will not work when the projects are installed using "system" packaging tools -- in such cases the__init__.pyfiles will not be installed, let alone executed.
Yet, I do not understand what these "system" packaging tools are. What are they? How could I reproduce this situation where the __init__.py files are gone?
@Anzel's comment looked like a good answer, and I'd say PEP-420 confirms that. In its Rationale section, we read:
Namespace packages are designed to support being split across multiple directories (and hence found via multiple
sys.pathentries). In this configuration, it doesn't matter if multiple portions all provide an__init__.pyfile, so long as each portion correctly initializes the namespace package. However, Linux distribution vendors (amongst others) prefer to combine the separate portions and install them all into the same file system directory. This creates a potential for conflict, as the portions are now attempting to provide the same file on the target system - something that is not allowed by many package managers. Allowing implicit namespace packages means that the requirement to provide an__init__.pyfile can be dropped completely, and affected portions can be installed into a common directory or split across multiple directories as distributions see fit.
So yes, we cannot add any more code to our __init__.py files because OS package managers (and others) would prefer to merge them into only one directory tree.