On Fri, 6 Nov 2009 17:50:46 -0600, Ian Bicking
My understanding is that they have all the same problems we do -- version management, dependencies, isolation, varying quality, etc.
Same problems. But CPAN does it a lot better.
When I've tried to install things from CPAN it's been surprisingly obtuse. This is not to say there aren't good things, but "we need CPAN" doesn't really get to the heart of it.
Works for me - it's like chalk and cheese - but python being the chalk in this case. Corporate contractor developers know the difference. Scientific dudes can obviously spot the difference. More than anything, it is a culture difference. CPAN is taken really seriously by those involved. There's so much passion to get things right and make things work smoothly. The "heart of it" is the CPAN culture. I never experienced the 'we don't support your platform' issue ever in perl. To CPAN, it is all just perl.
Testing is a bit off; "setup.py test" hasn't caught on that well..
In perl there is more incentive to provide this. In Python we don't have any place where this can be automatically activated on a package. So there is no incentive. The real world relevance would be some tests to ensure that the package can work on a number of different platforms and python versions before being accepted, and that the package has some tests that can be automatically run.
In terms of how a setup.py should be structured, and other developer packaging issues, I think we're getting closer but we *really* need someone to document the conventions and lessons that are usually just spread through copy-and-paste and developer feedback...
The individual components that we have are improving and we are getting closer to having something. But CPAN has an energy level behind it that we are yet to duplicate. David