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

[Benoît Bryon]

Hi,

I am looking for a convention (i.e. kind of PEP) about package names: 
"how to choose a good package name".
I couldn't find a PEP which gives guidelines about it.

PEP 8 gives some guidelines about "syntax" of package names.
I found articles like "Rules of thumb" section of 
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces. 
But I was looking for something more "official".
And thus, I was thinking of a PEP, or something similar.


Scope:

* we have tools to create and distribute packages. Not covered by this 
thread.
* we have tools to create namespace packages. Not covered by this thread.
* we have conventions about "syntax" of module names in PEP 8. Not 
covered by this thread.
* do we have conventions, or at least guidelines, to choose a name for a 
package?


I'm not to write this guide here (I'm not an expert about it), but, if 
such a PEP or documentation doesn't exist, here are some considerations 
to start:

* The Zen of Python tells "There should be one-- and preferably only one 
--obvious way to do it."
* 
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-namespaces 
seems interesting
* maybe 
http://guide.python-distribute.org/specification.html#naming-specification 
is a cool place
* maybe http://docs.python.org/dev/packaging/ is the right place for 
that kind of information
* We should cover both simple packages and namespace packages.
* I guess some teams or communities already have such conventions. As an 
example, does the Plone community have one?
* I feel there are too much de facto standards on Pypi: as an example 
Plone community uses namespaces like "plone.app.theming", whereas Django 
community uses "django-*" pattern, there are also many "pyramid_*" 
packages...
* We should cover public packages published on Pypi, but also public 
packages published on online repositories like Github, and also private 
(personal or corporate) packages.
* I know we cannot migrate existing package names.
* We could recommend something for new packages.


Here are quotes seen in a recent thread about PEP 420 
(http://mail.python.org/pipermail/import-sig/2012-May/000631.html), 
which make me believe a convention would be useful.
Notice that, in fact, I discovered PEP 420 while searching for a PEP 
about "how to choose a good namespace".


Le 13/05/2012 19:25, PJ Eby a écrit :
> Regarding the nesting issue and persuading Django developers to use 
> namespaces, I would note that there isn't any reason for namespaces to 
> be deeply nested in the first place.  By convention, top-level 
> namespace packages should be the name of a project or its sponsoring 
> organization, which means there is rarely a need for deep nesting.  
> Even cases like zope.app and peak.util are rare: usually a project or 
> organization will have only one such "miscellaneous" namespace with 
> lots of separately-distibuted components.
>
> (After all, the main reason to *have* a namespace package is to have 
> separately-distributed subpackages.  So, self-contained packages don't 
> need to have namespaces of their own, almost by definition.)
>
> Anyway, what I've noticed is that when people want to deeply nest 
> namespaces, it's usually because they're trying to share a namespace 
> across organizations, like making a shared 'net.*' namespace.  The 
> idea of namespaces isn't for that kind of categorization, though, it's 
> for *ownership*.  If two developers are fighting over where to put 
> something in a category hierarchy, it's a sign that they need to be 
> working in different namespaces, with each developer staking a claim 
> to a *top-level* package -- like OSAF's osaf.*, Zope Corporation's 
> zc.* (vs. the community project's zope.*), and so on.
>
> When developers use namespaces for project/ownership distinction, the 
> resulting package hierarchies can be pretty much as flat as you like.

If I had to explain it to another Python developer, I wish I could give 
him an hyperlink and say "read and follow the convention".


Le 13/05/2012 20:56, "Martin v. Löwis" a écrit :
> In Java, people apparently want that because they get these deeply
> nested directory hiearchies (org/apache/commons/betwixt/expression).
> It's apparently possible to condense this into
> org.apache.commons.betwixt/expression (which isn't a shorter string,
> but fewer cd commands / explorer clicks / .svn folders).
>
> I predict that people will start using PEP 420 in the reversed-domain 
> fashion also, so we eventually might end up wanting something like 
> this for Python.

Could we anticipate namespace usage? At least for some "simple" things 
that already are de facto standards.
As an example, I guess we could state about "reasonable maximum 
namespace depth", because on Pypi there is not many packages with more 
than 3 levels.


Regards,
Benoit