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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
