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

[Phillip J. Eby]

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
>information themself?

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?

Yes.

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

Such as?


>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 
the user).

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 
one whole).


>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 
status quo.