[Distutils] namespace packages ok to contain code?

[Brad Allen]

On Mon, Dec 13, 2010 at 7:21 PM, P.J. Eby <pje at telecommunity.com> wrote:
> At 05:11 PM 12/13/2010 -0600, Brad Allen wrote:
>>
>> Where I work we're considering a change to moving a group of packages
>> to using namespaces. We want the namespace paths to reflect a
>> dependency hierarchy,
>
> Note that you don't *need* to use namespace paths to reflect dependencies;
> the main purpose of namespace packages is to allow you to separately
> distribute parts of a larger package, and to avoid naming conflicts with
> code produced by other organizations.

> (In other words, it's a rare use case that really needs even *two* levels of
> namespace package; the common use is simply to make one parent namespace
> package for your organization. In general, the "flat is better than nested"
> rule of Python still applies.  ;-) )


Thanks for the guidance. In our case, after thinking through the
component design for a large application, we decided not to use the
namespace package part of the component name to describe
dependencies...that will be done by a different part of the component
name. Instead, we can use namespace packages for grouping components
with related functionality even when they exist at different levels
within the architecture (web components, model components, integration
components).

There are some functional areas where we really can't put those
functionally related components into the same package, so we really
will end up with some two-level namespace packages
(productname.functionalgrouping.model,
productname.functionalgrouping.web, etc). It's important to be able to
independently release those kinds of components to customers without
necessarily requiring an upgrade of the other related component.

This will introduce some manageability challenges with a large number
of module distributions but I think we can avoid dependency hell with
strict semantic versioning (per semver.org), good dependency
declarations in setup.py, comprehensive test suites, and use of
continuous integration to run tests and automate builds.

This can also be made manageable for developers by using buildout +
mr.developer + omelette (which I just learned about, and can't wait to
try out). See http://pypi.python.org/pypi/collective.recipe.omelette

Feel free to rain on my parade with a reality check :-) At this point
it feels a bit like going off the deep end, but this migration will be
done piecewise, not with one big cutover. It will be an interesting
exercise in seeing what the maturing Python build tools ecosystem has
made possible.