[Catalog-sig] [Python-Dev] setuptools: past, present, future

[Phillip J. Eby]

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").