conventions or best practice to choose package names?
Benoît Bryon <benoit <at> marmelune.net>
2012-05-13 21:44:22 GMT
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 - Distutils-SIG <at> python.org
http://mail.python.org/mailman/listinfo/distutils-sig
RSS Feed