Phillip J. Eby wrote:
It appears your goals are somewhat... confused.
I don't think so. I'm sure I still have to learn about setuptools but I think I know quite well what I want to achieve.
Remember that by definition a namespace package has no single "owner" project. It is potentially shared across multiple projects. When installed as an egg, each __init__.py is executed, true. But when a project is NOT installed via egg, but rather by a system packager, the __init__.py doesn't exist, and so cannot be executed.
If we have to take into account distributions of a project as source code bereft of its top-level namespace's __init__.py being expected to just work, I give up. I assumed to always work with either intact source or built eggs, the latter with or without their namespaces' __init__.py files being used and with or without being installed by our egg tools. The built egg has all the subdirectories needed and doesn't look different from other eggs in that respect. It doesn't rely on any namespace cleverness being performed by __init__.py, other than what setuptools already do for namespace packages. If the namespace mangling performed in that file was integrated with the setuptools' declare_namespace, there wouldn't need to be anything special about the __init__.py of a project with remapped package directories, and it wouldn't hurt if it wasn't executed anyway. In fact, the namespace package and all namespace subpackages could be given a standard __init__.py by setup bdist_egg. The package remapping is only needed when running from source, and I don't see a reason why the __init__.py shouldn't exist and be executed in that case.
Therefore, your prototype code is horribly broken, as it will corrupt pkg_resources' internal data structures when it is run more than once --
I don't see why it couldn't be made to behave properly. As I said, I'm still learning about setuptools, and I don't claim to be the most apt person to integrate any new functionality at this point.
(And I won't even get into the pointlessness of wrapping module-level code in an import lock.)
I'd appreciate it if you did, as I haven't yet found a difference between using the lock in modules and using it in pkg_resources.declare_namespace which is being called by modules. -- Thomas