[Distutils] Setuptools: omit namespace package directories?

Phillip J. Eby pje at telecommunity.com
Thu Feb 8 23:04:56 CET 2007

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

>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

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.

More information about the Distutils-SIG mailing list