[Catalog-sig] How to get a list of package releases
Phillip J. Eby
pje at telecommunity.com
Tue Jan 23 06:15:02 CET 2007
At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
>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.
To accomplish what goals? "Cleaner" can't be defined without reference to
some goal, like reduction of bugs, ease of extension/change, etc.
> Or is sourceforge magic going to stay?
>I always thought sourceforge support was temporary, just to ease
>migration toward setuptools.
The SourceForge magic is essentially gone as of 0.6c5; SourceForge fixed
their system so that neither screenscraping nor SF URL recognition is required.
> > 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
I still don't understand you. What will they be using that information *for*?
> If we can take out pain from PyPI user
>experience, we should do it.
You haven't shown that the absence of this information is causing anybody
any pain, beause I don't know what you are expecting anybody to *do* with
this information. I can't say I have ever needed this; I just install the
latest version, or I specify a specific version.
I can't recall ever wanting to find out "what versions are available", in
other words. So I still don't know what problem you're trying to solve.
>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?
"easy_install 'thepackage<0.8'" will find it and install it.
>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.
So does PyPI - you just have to manually follow the links right now, unless
you want it in *machine-readable* form (e.g. so you can then display it to
So, the use case of "I just want to know what releases are available" is
handled already, if you assume a human user. It may not be *convenient*,
but it is clearly *possible*.
>"We don't need this because nobody asked for it" is a really bad excuse
You seem to be under the impression that I said the feature isn't
needed. In fact, I am *still* merely trying to find out what problem you
are trying to solve!
This is an essential first step before trying to design a solution, but you
appear to be under the impression that people should somehow telepathically
know what problem you are trying to solve, perhaps by reverse-engineering
your proposed solution (which is underspecified in any event).
I think perhaps that you are also under the mistaken impression that I have
anything to do with how PyPI is maintained, developed, or operated; I only
maintain setuptools, so anything you want done server-side is another
issue. setuptools uses PyPI, but the two are conceptually distinct (unlike
say, CPAN, where the client and server are more-or-less considered parts of
>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.
Certainly there are UI (and other) improvements to PyPI that I would like
to see, and I've proposed/requested many of them on this list more than
once in the past. However, in the absence of volunteers to *implement*
those requested improvements, there is unlikely to be any change in the
More information about the Catalog-sig