On Feb 8, 2007, at 5:04 PM, Phillip J. Eby wrote:
At 05:05 PM 2/8/2007 +0100, Thomas Lotze wrote:
when using namespace packages, the corresponding package directories and __init__.py files must physically exist in the source tree, even though they can't, by definition of a namespace package, contain anything other than subordinate directories and a fixed stanza of Python code, resp.
I'm not sure that's entirely true, although they *do* have to exist when using "setup.py develop",
Yes. I think that's the main issue, as this is a very important use case. We rely on using develop eggs.
As Jim points out, nested namespace packages are usually a bad idea and shouldn't be created for new systems, as entry points are a better way of supporting third-party extensions to a package.
I don't think that the nested namespace was motivated specifically by this. It was simply a result of a natural human tendency to organize. :)
Since there's basically not information in those boilerplate directories and __init__.py files that couldn't be inferred from a keyword parameter to setup(), would it be a sensible feature request that setuptools do without the physical namespace directories in the future?
As I said, I'm not sure it needs them *now*, except to support setup.py develop.
Yes, as we need this.
I'm not really fond of the package_dirs feature, preferring to use an importable layout when I do development.
The question is whether a less annoying layout can be made importable.
But the feature does exist and please feel free to let me know whether it solves your problem,
It won't because of the need to support the develop use case.
I haven't really had a chance to think about this, so I don't know what a solution, if there is one, would look like. For me, this isn't critical, as it is merely annoying to have to create namespace package directories.