[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:
>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.
More information about the Distutils-SIG
mailing list