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

[Piotr Ozarowski]

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

How about PEP 396 (Module Version Numbers)?

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

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

> 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")
-- 
Piotr Ożarowski                         Debian GNU/Linux Developer
www.ozarowski.pl          www.griffith.cc           www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645