[Distutils] Setuptools: omit namespace package directories?

[Thomas Lotze]

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