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