[Python-Dev] PEP 423 : naming conventions and recipes related to packaging

Benoît Bryon benoit at marmelune.net
Thu Jun 28 12:53:47 CEST 2012


Le 27/06/2012 22:08, Yury Selivanov a écrit :
> With python adoption (enterprise too) growing, we will inevitably
> find out that one single namespace (PyPI) is not enough, and
> name collisions will become a frequent headache.

An argument for top-level namespace is related to PyPI
as a central place to publish Python code VS code
released in popular code repositories:
* many developers don't register projects with PyPI,
 even if open source. As an example, many projects
 are hosted on code repositories, such as Github.com,
 and not on PyPI.
* one reason (not the only one) is that, as an individual,
 publishing some "proof of concept" code at PyPI scares
 me:
 * it is very personal, at least at the beginning. Not
 sure it is interesting.
 * what if the project gets abandoned? It will remain
 on PyPI and block a name slot.
* on Github, people work in a user space. All projects are
 managed under the user account. Groups and companies
 can use organization accounts. This scheme seems popular
 and comfortable.
* on Github, people can fork projects. Project names are
 not unique, but "user/organization+project name" is
 unique. It seems to work well.
* sometimes, forks become more popular than original
 projects. Sometimes original projects are abandoned
 and several forks are active.
* Notice that distinct projects (i.e. not forks) can
 have the same name, provided they are owned by distinct
 users.
* Also notice that there is no deep nesting. There are
 only two levels: one for the user or organization, one
 for the project.
* if we consider PyPI as the unique reference and
 central place to check for (public) name availability,
 then shouldn't we promote registration with PyPI?
* there are other reasons why authors should register
 with PyPI. As an example the ability to ``pip install
 project`` without using complicated pip options.
* if many projects on Github are published on PyPI, then
 what would happen? I bet that, without adequate naming
 conventions, there will be many name collisions.
* so promoting top-level namespace (including individual)
 can help.
* a risk is that it also becomes difficult to find a
 project within PyPI. But having lots of projects in
 PyPI is not the problem. The problem is more or less
 related to the search. Meaningful names, memorable
 names and packaging metadata are important for that
 purpose. And if necessary, we will be able to improve
 PyPI search engine or list/browse views.
Benoit


More information about the Python-Dev mailing list

AltStyle によって変換されたページ (->オリジナル) /