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

[Jim Fulton]

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.

>> 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.


>
>> 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.

> 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?

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton