[Catalog-sig] [Python-Dev] setuptools: past, present, future
Phillip J. Eby
pje at telecommunity.com
Sat Apr 22 18:04:43 CEST 2006
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
>(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
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
>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").
More information about the Catalog-sig