[Distutils] Setuptools: omit namespace package directories?

[Phillip J. Eby]

At 08:59 AM 2/12/2007 +0100, Thomas Lotze wrote:
>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.

I meant the operational goals for the code you wrote, not your overall goal.


> > 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.

Built eggs contain namespace package __init__.py files, system-installed 
eggs do not.


>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.

Because 1) it won't be the only __init__.py for the package, and 2) how 
does it help you avoid having subdirectories for namespace packages?  You 
still have to have the directory to put the __init__.py in, and deeply 
nested namespace packages aren't a very good idea to begin with.  If it's 
only one or two layers deep, it's just as easy to do it the standard way, 
without package_dirs.


> > 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.

Perhaps it could.  I just don't see how!  In order to set up the __path__'s 
for a specific project, the __init__.py must have knowledge of *that* 
project.  Therefore, *each* project must contain such a file, *and* it must 
be executed.

Under setuptools 0.6, it's currently the case that all namespace package 
__init__'s (except those installed as system packages) are executed.

However, under setuptools 0.7, *at most one* will be -- which means that 
only *one* project will have a chance to do this munging, for its own paths.

(All of these things I'm saying are documented in the setuptools manual 
under the "Namespace Packages" heading, by the way.)


> > (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.

Runtime code that requests activation of an egg can currently result in 
declare_namespace() being called (see Distribution.activate()), and the 
import lock thus won't be held at that point in time.