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.
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 :).
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. Everyone could continue to push non-namespaced (flat) packages to pypi like now but the names couldn't take the form of namespaced ones. 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 don't think we would suddenly drown in namespace regs if we make it a pre-condition that there need to be a couple of existing real packages that would go into it. cheers, holger
Jim
-- Jim Fulton http://www.linkedin.com/in/jimfulton _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig