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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
