[Catalog-sig] How to get a list of package releases

Michał Kwiatkowski constant.beta at gmail.com
Tue Jan 23 03:54:46 CET 2007

On 1/22/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 05:15 PM 1/22/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> >Currently we have a lot more logic in the client (easy_install) than
> >in the server (PyPI). So now we have this strange situation when an
> >installation client knows more about a package than the packages
> >server. Shouldn't we constantly move toward removing magic from
> >setuptools and porting important bits to PyPI?
> I dunno.  What actual problem are you trying to solve, or what use case
> are you trying to support?

Cleaner architecture probably. Or is sourceforge magic going to stay?
I always thought sourceforge support was temporary, just to ease
migration toward setuptools.

> For example, why do you want to know what versions are available *in an
> automated way*?

Why we write programs at all? To automate things we don't want to
repeatedly do ourselves. If setuptools is so good at finding available
versions of a package, why should we force user to find these
information themself? If we can take out pain from PyPI user
experience, we should do it. You already done that for finding out
download locations with easy_install. Users don't have to click links
and find eggs themselves. The same goes for finding out available
versions. Since this data is already available to setuptools I really
don't understand why we should not port this to PyPI, so that users
will be able to check their options even without setuptools installed.

Maybe you ask about why on earth someone needs a list of releases?
Well, maybe someone finds a bug in current release and want to try
earlier version. If the current release is 0.8 how user will know what
was the previous? Was it 0.7? 0.7.5? Maybe 0.8rc3? Of course there are
more use cases. I don't really understand why this have to be
explained - probably each package index out there (freshmeat, CPAN,
rubyforge, sourceforge, berlios) have a list of releases available. Of
course there is a possibility that this functionality is useless and
I'm the only one that needs it, but IMHO chances for that are slim.

The thing with PyPI is that it really needs usability improvements. We
hear complains from time to time on this list, sometimes in
blogosphere, about things like non-functional search or broken links
etc. Complains aren't the problem - because we can react to these -
problem is with general user experience. If a user won't find what he
is looking for on PyPI he probably won't shout about it, but will go
somewhere else (like CPAN or Rubygems). "We don't need this because
nobody asked for it" is a really bad excuse. Setuptools may do a great
job at the low level but the whole system may suck because user is
pushed off because of bad PyPI experience.

Having said that I'll try to propose few more improvements in oncoming
weeks, that will make PyPI experience better, I hope. If you have any
suggestions on what is lacking, I will love to hear them.


More information about the Catalog-sig mailing list