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

Donald Stufft donald at stufft.io
Sun Jun 2 17:49:34 CEST 2013


On Jun 2, 2013, at 11:25 AM, Jim Fulton <jim at zope.com> wrote:

> On Sat, Jun 1, 2013 at 3:21 PM, holger krekel <holger at merlinux.eu> wrote:
>> On Sat, Jun 01, 2013 at 11:57 -0400, Jim Fulton wrote:
>>> In the Python community, we've been pretty laid back
>>> about how we name packages.  When we were small, this made
>>> sense.  It doesn't make sense any more.
>> 
>> I've heart this sentiment before, but would like to read more
>> clearly stated problems.
> 
> I thought the problem was pretty clear: name collisions.
> 
> There's a parallel thread on how to detect and reclaim
> names that are taken and unused.  I think if we had a more
> systematic way of naming packages, this wouldn't be an issue.

I think the parallel thread mostly involves people wanting specific names
that are no longer available. I know I've claimed a few good names at the
start of an idea then abandoned the idea and forgotten to deregister the name.

There are still lots of good names but people get attached to ones they like
and it feels kinda shitty when you have to rename your project because of
a placeholder that's been there for 3 years that you didn't notice.

> 
>>> We should not have to come up with a process for recognizing squatters
>>> on simple package names.  We should have something more systematic,
>>> IMO.
>>> 
>>> Unfortunately, I think the sanest way of avoiding most package
>>> name issues is to base them on domains, as is done in the Java
>>> world.  This goes against the Python philosophy of preferring
>>> flat to nested, but I still think it's better than trying to police squatters,
>>> or to encouraging races to claim top-level names.
>> 
>> I am not sure that tying to DNS namespacing is the only solution here
>> (whatever the problem is exactly :).
> 
> It's not the only solution, but it's a pretty easy one.  It avoids (more
> more precisely reuses) a central naming authority. It's the technique
> used by the java ecosystem and by XML namespaces, for example.

We already have a central naming authority it's called PyPI ;)

> 
> 
>> 
>>> 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.
> 
> We could.  Maybe that's the most palatable alternative.  It has the
> huge benefit of promoting relatively flat, Pythonic, namespaces.
> 
> It has disadvantages:
> 
> - We have to set up some sort of naming authority.
> 
> - It's probably not scalable.

As mentioned above we already have an authority, and it's more or less scaled
quite fine so far. I still continue to be able to get very good names, but sometimes
it takes a few tries to find an unused one.

> 
>> Everyone could continue to push non-namespaced (flat) packages to pypi
>> like now but the names couldn't take the form of namespaced ones.
> 
> I'm not sure what you're suggesting here.
> 
> Are you saying someone could publish a package named: "zc",
> bit not "zc.foo"?
> 
> Or are you saying that publication of a package named "bar" would
> prevent someone from creating a "bar" namespace, and the
> other way around?

This is likely implementation details, but if I were to do it then folks could
apply for a particular namespace, (For example zc.*) and it would give
them ownership over all levels of that namespace, (in our example, zc,
zc.foo, zc.bar, zc.foo.bar, etc but not zc4 or zc4.cool).

However they would only own that namespace if they've applied and been
granted it. Otherwise anyone is free to register packages in that namespace.

And for what it's worth Organization accounts is something on my roadmap for
PyPI.

> 
> Jim
> 
> -- 
> Jim Fulton
> http://www.linkedin.com/in/jimfulton
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130602/ff8c40b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130602/ff8c40b1/attachment.pgp>


More information about the Distutils-SIG mailing list