[Catalog-sig] How to get a list of package releases
constant.beta at gmail.com
Sat Jan 27 18:07:51 CET 2007
On 1/23/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 03:54 AM 1/23/2007 +0100, =?ISO-8859-2?Q?Micha=B3_Kwiatkowski?= wrote:
> > 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
Still sourceforge is treated in a special way. Users of other systems
have to manually put their links/files on PyPI. Is this special
support going to stay? And is it working, for example, with
> >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.
What if user doesn't have easy_install installed when he is looking
for an answer? Maybe he knows where in the code the problem lies, so
he want to check earlier versions' code without installing? Maybe he
want to skim through changelog?
> >Of course there are more use cases.
> Such as?
You said sometimes you need a specific release. So you may be told you
need 0.7. You may just go and try to do easy_install==0.7. Or you may
look at list of releases and check if 0.7.5 is there. 0.8rc2 won't buy
it, so doing easy_install<0.8 won't work here.
Sometimes you're just looking at available libraries for doing a
specific task. You may want to look at a few versions of a package
from any computer, even if it doesn't have easy_install installed (or
even Python for that matter). PyPI should be usable on itself, it's a
web interface after all. We can't assume that every PyPI user have
easy_install on his local machine.
List of packages is also useful for historical reasons. A library that
had few dozens of releases starting from 2003 is probably better
tested than a library with three versions released this year.
> >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).
What links? Where are the links for all published releases of a given
package? Did I miss something?
> >"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!
Again: "PyPI can't show a list of package releases" (isn't this in a
message subject?). Is this a problem? Maybe not. Does other popular
package indexes have it? Yes. (I don't even know one which doesn't
have it) It may be that everyone is wrong and solved non-existing
problem with this functionality, but I goes not.
> 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).
I think who mantains what isn't an issue here. What matters is user
experience and this binds PyPI and setuptools very tightly.
> >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.
Talking about whenever an average PyPI user would need a given
functionality won't change it either. So lets just say I'll implement
this, it will get merged and we'll look at some PyPI logs after some
time. If people use it (for whatever reason) - it will stay.
I'm currently during my exam session but it will hopefully end soon,
so I'll have some time under my belt to implement some functionality
for PyPI. Feel free to post your list of changes you'd like to see in
PyPI, so we'd have better understanding of what is needed. Or even
better: update TODO on http://wiki.python.org/moin/CheeseShopDev (I
don't know if it's up-to-date and represent real needs, so claryfing
that would be nice as well).
More information about the Catalog-sig