Hi Jeff, On Sat, 07 Nov 2009 06:04:15 -0600, Jeff Rush <jeff@taupro.com> wrote:
I keep reading and I keep hearing you and others saying this, but as someone who has never used CPAN, I'm not seeing the large number of specific implementable tasks that CPAN clearly has and PyPI clearly does not.
ok. Fair enough. Let me clear up the terminology. In perl, CPAN means packages + local perl + repository In python, pypi means repository. If people complain about pypi versus cpan, the complaint actually has nothing to do with pypi. What they are actually complaining about is the package management support (or lack thereof) that is built into python. Let me say it a different way... "Where can I find the pypi module in python?" Of course there is no pypi module in python. That's why this whole thing is just so confusing. If there was such a thing as a pypi module, then users would automatically use that to access pypi and download and install packages. But what python offers is: - setuptools - distribute - pip - distutils In perl, there's only one word for everything, cpan. Even though it's components exist as libraries and command interfaces on the local system.
Without handwaving please, in a technical sense what does CPAN have that is so wonderful other than the items mentioned so far of:
- buildbot on the server - mirrored. hierarchical servers - one widely known and accepted way of doing packaging
+ Easy to find Modules and command interfaces to interface to the repository that exist on the local machine. All carrying the matching cpan name.
If we implement those, if we implement PEP 381, in what specific way will we still fall *far short* as you suggest?
Pypi itself isn't a problem. Buildbots for packages shouldn't go on pypi itself in any case. They should go on an entirely seperate server. So, let me sum up. Pypi itself has no major external problem. It's short on a package buildbot and local python has no pypi module. Add a package buildbot and add a pypi package support and we're pretty much caught up. David