[Distutils] Setuptools: omit namespace package directories?

[Thomas Lotze]

Am Mon, 12 Feb 2007 11:38:13 -0500 schrieb Phillip J. Eby:

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

Well, this is probably subject to personal preferences. I don't find a
better answer to this than that I do find one or two levels too few for
some things (maybe that's the german in me for all the desire to keep
things orderly ;o)), and that I personally do find all the directory
jumping this implies annoying.

I mean, one top-level namespace for an organization or for a person to
avoid stepping on other people's toes in terms of package names, one for
a project, and maybe one for a bit of structure within a project, like
modules, plugins, recipes, whatever. Seems sensible to me and makes for up
to four-part dotted names - YMMV.

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

Ah, this is the point where my scheme breaks apart.

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

The crucial sentence in the docs is "If the first loaded __init__.py
doesn't declare it, it will never be declared, because no other copies
will ever be loaded!", which obviously refers to setuptools 0.7 while I
was thinking in terms of (and your assertion that "When installed as an
egg, each __init__.py is executed" probably referred to) 0.6.

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

OK, thanks.

-- 
Viele Grüße,
Thomas