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
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
