Re: [Distutils] Setuptools: omit namespace package directories?
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.
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.
participants (2)
-
Phillip J. Eby -
Thomas Lotze