[Distutils] conventions or best practice to choose package names?

Jim Fulton jim at zope.com
Mon May 14 13:12:56 CEST 2012


On Sun, May 13, 2012 at 5:44 PM, Benoît Bryon <benoit at marmelune.net> wrote:

...

> Le 13/05/2012 19:25, PJ Eby a écrit :
>>
>> Regarding the nesting issue and persuading Django developers to use
>> namespaces, I would note that there isn't any reason for namespaces to be
>> deeply nested in the first place.  By convention, top-level namespace
>> packages should be the name of a project or its sponsoring organization,
>> which means there is rarely a need for deep nesting.  Even cases like
>> zope.app and peak.util are rare: usually a project or organization will have
>> only one such "miscellaneous" namespace with lots of separately-distibuted
>> components.
>>
>> (After all, the main reason to *have* a namespace package is to have
>> separately-distributed subpackages.  So, self-contained packages don't need
>> to have namespaces of their own, almost by definition.)
>>
>> Anyway, what I've noticed is that when people want to deeply nest
>> namespaces, it's usually because they're trying to share a namespace across
>> organizations, like making a shared 'net.*' namespace.  The idea of
>> namespaces isn't for that kind of categorization, though, it's for
>> *ownership*.  If two developers are fighting over where to put something in
>> a category hierarchy, it's a sign that they need to be working in different
>> namespaces, with each developer staking a claim to a *top-level* package --
>> like OSAF's osaf.*, Zope Corporation's zc.* (vs. the community project's
>> zope.*), and so on.
>>
>> When developers use namespaces for project/ownership distinction, the
>> resulting package hierarchies can be pretty much as flat as you like.

Well said.  IMO, only one level of nesting is necessary.  When I've
used nested namespaces in the past, it was out of a compulsion to
over-organize. :)

But:

> Le 13/05/2012 20:56, "Martin v. Löwis" a écrit :
>>
>> In Java, people apparently want that because they get these deeply
>> nested directory hiearchies (org/apache/commons/betwixt/expression).
>> It's apparently possible to condense this into
>> org.apache.commons.betwixt/expression (which isn't a shorter string,
>> but fewer cd commands / explorer clicks / .svn folders).
>>
>> I predict that people will start using PEP 420 in the reversed-domain
>> fashion also, so we eventually might end up wanting something like this for
>> Python.

If Python were more popular, I think we'd be more like Java in this
regard.

When I create a package like ``zc.thread`` it allows me to use a
package named ``thread`` without being presumptuous and trying to
claim a top-level name like "thread". But "zc" is a little
presumptuous too.  Might there someday be another organization who's
initials are "zc"?

Lately, I've gotten the impression that people are rejecting the use
of namespace packages altogether. There's an incorrect notion that
namespace packages are an invention of setuptools.  I think this is
unfortunate.

+1 for an official document (or addition to an existinhg document)
   providing a rational for namespace packages and their naming.

Jim

--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://www.dublinstore.com/


More information about the Distutils-SIG mailing list