[Catalog-sig] [Distutils] We need to make a decision wrt distribution names
waterbug at pangalactic.us
Wed Jul 25 03:56:17 CEST 2007
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.
More information about the Catalog-SIG