[Distutils] Sooner or later, we're going to have to be more formal about how we name packages.

[Jason R. Coombs]

From: Distutils-SIG
[mailto:distutils-sig-bounces+jaraco=jaraco.com at python.org] On Behalf Of
Donald Stufft
Sent: Saturday, 01 June, 2013 15:30
To: holger krekel
Cc: distutils sig
Subject: Re: [Distutils] Sooner or later, we're going to have to be more
formal about how we name packages.

 

 

On Jun 1, 2013, at 3:21 PM, holger krekel <holger at merlinux.eu
<mailto:holger at merlinux.eu> > wrote:





On Sat, Jun 01, 2013 at 11:57 -0400, Jim Fulton wrote:




For a while, many of us have been pretty careful to use namespaces
for new packages to mitigate this issue.  For example, the zc namespace
is a shorter version of com.zope, but at some point, it won't be fair
for us to claim zc for ourselves.


I wonder if we could allow people/groups to apply (to humans) for a
namespace which they can subsequently control, like the "zc.*" one.

 

So for example if the django community wants to introduce the concept
of "vetted" plugins/addons, they could move to manage "dj.*" or so.



 

I think this example highlights some of the challenges with
registering/controlling namespaces - who owns what and what is the meaning
of a (distribution) package name? For example, what is the namespace used
for an endorsed django plugin written by zope corporation?

 

This problem is not present now, as the author can choose the domain which
is most relevant to that plugin and its users. If there's some expectation
that it should appear in a namespace managed by another organization, that
necessitates a coordination between the namespace owner/manager and the
project author.

 

I think more people would claim namespaces when namespaces are better
supported in Python. My expectation is Python 3.3 namespace package support
will ease that challenge (when it becomes a dominant version).

 

My inclination is to say it's not a huge problem, and later is preferable
than sooner.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130601/a5bd4c67/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6572 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130601/a5bd4c67/attachment.bin>