[Distutils] conventions or best practice to choose package names?

[PJ Eby]

You've definitely put in a lot of work on this, and most of the actual
guidelines in your PEP are quite good.  I think there's a core part of this
that can and should be a good Informational-track PEP.

However, I do have a few comments regarding overall organization, and some
regarding some of the specific recommendations and tone.

In order of appearance in the PEP, they are:

1. I would strongly suggest striking the aside on eggs entirely -- there's
no point to bringing it up just to dismiss it, and there never was such a
thing as an "egg name" - eggs are just another kind of distribution, so
they don't need a special term.

2. A project name isn't the name of a directory, it's the name of the thing
you release distributions of.  E.g., my "Importing" project on PyPI (
http://pypi.python.org/pypi/Importing), which has the following names:

a) Project name = Importing
b) Release = 1.10
c) Distribution = Importing-1.10.zip
d) Module = peak.util.imports

Following this conceptual breakdown will make the naming recommendations
easier to follow.

3. The rationale is unnecessary and could (and *should*) be cut entirely.
Use PEP 8 as a model - it doesn't waste time explaining why coding
guidelines are a good idea.  The truth is, your PEP would be massively
improved simply by deleting this entire section and not even trying to
replace it with anything.

4. The proposal section is also unnecessary, and likely to produce
resistance in any event.  There is no reason why every package should use
your approach, and some developers will be opposed to your conventions.  (I
disagree with some of them myself, for that matter, as I will discuss
below.)  Some of the material from this section might make a good later
section on "How to apply these guidelines to your project".

5. The actual guidelines are pretty good, as I said.  In particular, I like
pretty much every thing you say about package names.  I disagree with some
of your assertions regarding project names, however.  It's true that a
project name doesn't need to spell out what a project does (as with Celery,
Nose, etc.), but it does in fact hurt discovery and use when people use
package-based project names.  It's a continuing source of frustration, for
example, that buildout recipe projects have names like z3c.recipe.scripts
and other names that I can't ever remember, and am forced to re-google or
dig up previous buildout files to find the magic names to include in my
buildouts.  To me, the  important thing about a project name is that it be
*memorable*, and that argues against using namespaced package names as
project names for contributions to a larger project, such as Plone
portlets, Buildout recipes, etc.

This isn't a huge point of contention for me, I just want to point out that
the good naming choices for projects are more complicated than "just use
the package name and let people search for it".  I think there are some
other points you made that are a little too cut-and-dried in the same way,
but this is the only really big one.

6. Drop the language about how things are supported or not supported.  This
just isn't true: Python the language supports you nesting things 6 layers
deep if you feel like it, and AFAIK there are no plans to change that, nor
should there be.  Stick to talking here about what is or isn't a good idea,
not what's supported or not supported.  That's just FUD.

7.  PyPI should be the only place people have to check for a registered
distribution name; authors of projects that are hosted elsewhere can and
should use "setup.py register" to claim the name, or log on and do it.

Anyway,  as I said, I think you've got some really good stuff here, but
it's got a lot of other stuff hiding it.  Cut away the extras (and the
parts implying these guidelines are mandatory) and you've got a good
Informational-track PEP.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20120531/add7e4ca/attachment.html>