Question: Consequences for packages with conflicting top level directory

Packaging
#1

There is a non-namespace package pkg:

pkg/__init__.py (non-empty)
pkg/file1.py
pkg/lib/file2.py

Someone adds a “semi-namespace” package pkg_extras with same top level directory pkg

pkg/extras/__init__.py
pkg/extras/extras.py

What can go wrong here

Previously I thought that uninstalling one of the packages breaks another since they both think they own the root directory pkg. But this does not seem to be the case in practice. Uninstalling pkg_extras only deletes “pkg/extras/" and when uninstalling pkg, it tries to delete "pkg/”, but preserves the “pkg/extras/*” files.
So, is there still an issue with using the same root directory/module in non-namespace packages?

P.S. We’ve also added __path__ = __import__('pkgutil').extend_path(__path__, __name__) to the non-empty pkg/__init__.py file, but I do not fully understand what this really does. Can you help me understand that line and whether it’s beneficial or detrimental for this case?

#2

Pip only tracks files that are installed, and will remove empty directories after deleting the last file. So provided there are no filename collisions, this approach is fine.

It also avoids the need for any other namespace handling, as provided the core package is present (that provides the __init__.py file), Python itself doesn’t need any extra help.

And since Python 3, it’s possible to do it without the __init__.py file. However, this relies on the user not having any conflicting names in their environment, which is generally more difficult to ensure than simply including the __init__.py file.