At 12:34 PM 4/22/2006 +0200, Fredrik Lundh wrote: >Guido van Rossum wrote: > > > Leaving aside the Perl vs. Py thing, opinions on CPAN seem to be > > diverse -- yes, I've heard people say that this is something that > > Python sorely lacks; but I've also heard from more than one person > > that CPAN sucks from a quality perspective. So I think we shouldn't > > focus on emulating CPAN; rather, we should solve the problems we > > actually have. > >the first problem seems to be to define what those problems really >are ;-) > >(as for the CPAN quality, any public repository will end up being full >of crap; I don't see any way to work around that. automatic scoring >based on superficial aspects
The purpose of automated scoring on superficial aspects isn't so much to ensure quality as it is to ensure *accessibility*, both in the sense of being able to install the thing, and meet some basic levels of having documentation. If something is accessible and trivial to install, then the market can decide which packages are better to actually use. >or ratings by small numbers of anonymous >visitors are probably among the worst ways to distinguish crap from >good stuff; for quality, you need initiatives like > > http://code.enthought.com/enthon/ > >and other "fat python" projects. Actually, every project that uses other projects' code can now be a "chubby python" by expressing dependencies. Really, one of the best ratings of a package's quality (or at least popularity) is going to be how many other projects depend on it. If everybody uploaded eggs to the Cheeseshop, it'd be possible to show links to "projects that use this project's code" by reading the dependency metadata with pkg_resources. (Not to mention "projects that this project uses"). _______________________________________________ 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
