[Distutils] Setuptools: omit namespace package directories?

[Thomas Lotze]

Jim Fulton wrote:

>> when writing a buildout recipe, the cleanest thing is to use several
>> namespaces, like zc.recipe.egg does.
> 
> I don't agree that this is cleanest.  I made a mistake by introducing the
> recipe namespace.  New recipes I write won't use this.  "Flat is better
> than nested."

To comment on buildout specifically, which I had only brought up as an
example, though:

  While I agree with "flat is better than nested" most of the time, I
  don't when it comes to buildout recipes. It's the nature of buildout
  that some recipes deal with software that has a name of its own, or 
  with general concepts. You wouldn't want to call a recipe for installing
  libfoo something like zc.foo or zc.libfoo as everybody would think it's
  your libfoo binding, and a name such as gocept.download is a bit too
  non-descriptive for my taste. So there should be a hint at buildout or
  recipes in the (dotted) name. Personally, I prefer a recipe namespace
  for recipes that deal with third-party software or generalities, and a
  recipe subpackage for one's own projects. Anything else feels rather
  non-elegant to me, but this might just be a matter of taste. What's your
  preferred naming scheme for new recipes?

> Also, for smaller projects, I'm avoiding intermediate src
> directories to avoid the annoying nesting.  (I'm a little uneasy about
> this, but can't see a serious downside other than setup being importable
> in develop mode.)

I do this all the time myself.

> IMO, the only needed hygiene is the top-level namespace.  (Maybe a huge
> organization would need sub namespaces, but we don't.)

I don't think it's a matter of running out of names when you have to name
too many unrelated things, but one of finding concise and descriptive
names for related or generic stuff. Descriptive and unique names in a flat
namespace tend to grow long and in some cases, unreadable unless you
violate PEP 8 and  stick in an underscore or two.

For example, I'm writing a bunch of buildout recipes for Apache stuff, and
I'm not going to choose names such as tl.apache or tl.buildoutmodpython.
Without introducing a namespace for my buildout recipes, buildout_apache
and buildout_modpython is the least annoying naming scheme I can come up
with. (BTW: Did I just miss something, or do recipes for these really not
exist yet?)

>> 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?
> 
> I would love to see this.  I haven't been able to think of a good way to
> do it reliably, especially considering the important use case of develop
> eggs, which want to run directly from a checkout.

I'd have to look closer at what eggs do to Python's importing mechanism,
but naively I'd hope that if it's possible to find a subpackage in one of
several eggs that all hold parts of its top-level package, it should be
possible to find it in some other place. Installing a develop egg would
then have to mean more than placing a link file somewhere, possibly a stub
egg for the namespace package. Maybe this is day-dreaming, though - I'll
have to study setuptools first.

-- 
Thomas