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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
