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.