Report #16088
[bug\_fix] Namespace package collision between pkg\_resources and PEP 420
Remove \`\_\_init\_\_.py\` from namespace directories \(e.g., \`company/\`\) and migrate from \`namespace\_packages\` in \`setup.py\` to PEP 420 implicit namespace packages using \`find\_namespace\_packages\(\)\` or modern \`pyproject.toml\` backends.
Journey Context:
A developer maintains \`company.analytics\` which uses the legacy setuptools namespace package pattern: a \`company/\_\_init\_\_.py\` containing \`\_\_import\_\_\('pkg\_resources'\).declare\_namespace\(\_\_name\_\_\)\` and \`namespace\_packages=\['company'\]\` in \`setup.py\`. They install another package \`company.logging\` from PyPI which uses modern PEP 420 implicit namespace packages \(no \`\_\_init\_\_.py\` in \`company/\`\). When importing \`company.analytics\`, they receive \`ImportWarning\` about module rewrites or \`ModuleNotFoundError\` for submodules of \`company.logging\`. Debugging reveals that \`pkg\_resources\` is rewriting the import machinery to create a legacy namespace package at \`company\`, which conflicts with Python 3.3\+'s native handling of implicit namespace packages. The \`company\` directory cannot simultaneously be a PEP 420 implicit namespace and a pkg\_resources legacy namespace. The fix involves removing \`company/\_\_init\_\_.py\` entirely, removing the \`namespace\_packages\` argument from \`setup.py\`, and using \`setuptools.find\_namespace\_packages\(include=\['company.\*'\]\)\` \(or equivalent in \`pyproject.toml\` with \`hatchling\`/\`flit\`\). This aligns with PEP 420, allowing multiple distributions to share the \`company\` namespace without import machinery conflicts.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T01:48:28.528792+00:00— report_created — created