Phillip J. Eby wrote: > At 01:09 PM 7/24/2007 -0400, Stephen Waterbury wrote: >> Actually, I wasn't confused. :) I'd suggest a convention that allows >> a distribution "title" (e.g., "Zope", "Twisted", etc.) and a >> distribution "name" that would simply be the name of the >> distribution's top-level package (e.g., "zope", "twisted", etc.), > > This proposal would rule out namespace packages ...
I thought about that. The rule for namespace distributions would be to allow dotted names, e.g. "zope.interface", "zope.schema", etc., as are often currently used. In fact, in a real sense, those *are* the top-level packages of namespace packages. > in addition to being > incompatible with existing distribution names. I thought the point was to come up with a new distribution naming convention, because there currently isn't one -- but the naming convention has to be consistent with all existing distribution names? Seems a tough constraint. > Note that package != distribution ... Yes, I knew that. Of course, now the discussion seems to suggest "project" or "project release" might be a better name than "distribution", and I agree with that. > -- a distribution may contain zero or > more packages (even top-level) ... Indeed, and I've always disliked multiple top-level packages in an [installable unit]. I never liked ZODB strewing top-level packages all over site-packages. (But I do like ZODB -- thanks Jim et al.! I'd just much prefer that it have a top-level "zodb" package.) Of course, eggs make site-packages dirs look much tidier, but I'd still prefer that each [installable unit] have a top-level package, because then it's obvious where imported modules come from just by looking at their top-level namespace. > *and* a single package (top-level or > otherwise) may be spread over more than one distribution. IMO, a package that's spread over more than one distribution should probably not be top-level in both distributions. :) BTW, I am not emotionally attached to this proposal (good thing, eh? ;), but there are a couple of principles in it that I thought deserved a little bit of logical advocacy, e.g.: * if a package deserves a "top-level" namespace, it probably also deserves have its own [installable unit]. * although package != [installable unit], I still think it's not illogical to use the top-level package of an [installable unit] as part of its canonical unique identifier. But admittedly one would have to agree with some of my other points above to agree with that. Steve _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
