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