[Python-Dev] PEP 423 : naming conventions and recipes related to packaging (original) (raw)
Benoît Bryon benoit at marmelune.net
Thu Jun 28 12:53:47 CEST 2012
- Previous message: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging
- Next message: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 projectwithout 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
- Previous message: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging
- Next message: [Python-Dev] PEP 423 : naming conventions and recipes related to packaging
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]