At 05:05 PM 2/8/2007 +0100, Thomas Lotze wrote:
Hi,
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", or they won't be importable. Have you tried using the distutils package_dir mapping to remap your source tree?
This gets annoying, especially when using nested namespaces. For example, when writing a buildout recipe, the cleanest thing is to use several namespaces, like zc.recipe.egg does.
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. Thus, having a single top-level namespace to denote a publisher or product line is usually sufficient.
However, you end up jumping through essentially empty directories all the time while working on the source. There's evidence that this problem is a real one: buildout recipes registered with PyPI tend to omit the "recipe" part at the expense of namespace hygiene and PEP 8 compliance, for example gocept.download or buildout_script.
I don't understand.
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. I'm not really fond of the package_dirs feature, preferring to use an importable layout when I do development. But the feature does exist and please feel free to let me know whether it solves your problem, or report *specifically* what it does or does not do correctly and what output is produced. Thanks.