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
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,
> > 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
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.