On Jun 2, 2013, at 11:25 AM, Jim Fulton jim@zope.com wrote:
On Sat, Jun 1, 2013 at 3:21 PM, holger krekel holger@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@python.org http://mail.python.org/mailman/listinfo/distutils-sig
----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA