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.