On Mon, Dec 13, 2010 at 7:21 PM, P.J. Eby <p...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
