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

Benoît Bryon benoit at marmelune.net
Fri Jun 29 15:05:01 CEST 2012


Le 29/06/2012 12:50, Piotr Ozarowski a écrit :
> [Benoît Bryon, 2012-06-29]
>> Le 28/06/2012 14:15, Piotr Ozarowski a écrit :
>>> [Benoît Bryon, 2012-06-27]
>>>> http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt
>>> I think PEP 386 (about versions) should be mentioned in "Relationship
>>> with other PEPs" section.
>> Why? Right now, I can't see the relationship between
>> projects/packages/modules names and versions.
> The PEP name is "Naming conventions and recipes related to packaging"
> and version numbers are related to packaging (and naming) for sure.
Ok. Maybe the title of the PEP is not clear.
It is related to naming conventions only, and only in
packaging (i.e. projects, and distributed packages or
modules, not variables, function or class names).

Would "naming conventions related to packaging" be better?


> How about PEP 396 (Module Version Numbers)?
How are version numbers related to naming?


>>> About "Use a single name" section: sometimes one needs to add "python-"
>>> or "py" prefix to project name (f.e. if the name is already used in
>>> other programming languages and you cannot register it in your favourite
>>> forge hosting service)... but please don't add the prefix also in namespace.
>>> All these PyQts, pyudevs, pygames and pyopencls sound stupid to me (isn't
>>> it obvious that when I do `import foo` in Python, "foo" is a *Python*
>>> library?)
>> Do you mean:
>>
>> * "pip install pyqt" =>   yes,
>> * "import pyqt" =>   no,
>> * "import qt" =>   yes?
> right
>
>> Currently, if the project name is "pyqt", then the PEP
>> proposal recommends "pip install pyqt" and "import pyqt",
>> to make the name consistent. If one is not a good choice,
>> change both.
>> It is convention over configuration.
> that's my point, PyQt guys cannot use Qt as project name, but
> "qt" it a better name for this namespace, IMO
>
>> IMHO, a "py" prefix for package name would not be a problem
>> in this case. You are not importing Qt itself, but Python
>> bindings for Qt.
> it's not "a problem", I just think PEP should not recommend such
> prefixes

By now, I feel that the "py" prefix use case is not special enough to
reconsider or break the "use a single name" rule.
I would accept to "import pyqt" instead of "import qt".
But that's my own viewpoint. I understand you don't subscribe to it.

May someone else enter the discussion and give his opinion about this
point?

>> I mean, yes, it is obvious that when I do `import foo` in
>> Python, then "foo" is a *Python* library. But would the
>> reverse assertion be that if I see "import qt" in Python
>> code, then it is obvious that Qt itself is a Python library?
> There's a "readline" package in Python's stdlib, does it imply readline
> is something Python related or specific?

You are right. My bad :)

>> The name could have been "qtbindings", would have it been a
>> problem then? The "py" prefix has the advantage to be clear:
>> that's *Python* bindings for Qt. And it's a really short
>> prefix.
> qtbindings, qtlib or other similar prefixes/suffixes should not be
> recommended, IMHO
>
>>> About ".contrib.": flask uses flask.ext.foo (namespace) and Flask-Foo
>>> (project name) schema for Flask extensions - maybe it's worth mentioning
>>> in this PEP as well.
>> Maybe it will be used in discussions or in examples, but
>> I suppose the PEP is not the place to list all project-specific
>> conventions. Currently the draft PEP tells: "search for
>> specific conventions in main project (Flask) documentation".
> I just thought "foo.ext.bar" is a nice convention worth mentioning
> (next to, not instead of "contrib" which is more general than "ext")

I agree that "foo.ext.bar" seems nice... but it uses 3
namespace levels. It breaks the "avoid deep nesting"
rule, which recommends not more than two levels.
So the PEP can't recommend this pattern, or we will also have
to reconsider the "avoid deep nesting" rule.

Notice that, from current feedback about the PEP, I understand
that the "avoid deep nesting" rule sounds more valuable than
the "standard pattern for contributions".

About naming pattern for contribs, the draft PEP proposes:

* to use "foocontrib.bar" by default
* if there is a need to separate "extensions" from "contributions"
   (supposing the difference is clearly documented), the project
   can tell his users to:

   * publish contributions in foocontrib.*
   * publish extensions in fooext.*

That said, in that particular case, I would publish everything
related to foo (except foo itself) in the same namespace
(i.e. only foocontrib.*) and use metadata to categorize projects.
As an example, with something like keywords="foo extension".
So that:

* there is only one namespace package

* everything that is "related to foo" is under foocontrib.*

* if the "contribution" VS "extension" terminology change,
   there is no need to move projects from one namespace to
   another.

* a project can be both an extension and a contribution.

* it's possible to filter the list of packages at PyPI to
   get the list of extensions: name starts with "foocontrib."
   and has keyword "extension".


Benoit



More information about the Distutils-SIG mailing list