[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