On 1/23/07, Phillip J. Eby <[EMAIL PROTECTED]> 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 > required.
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 BerliOS-hosted projects? > >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). Cheers, mk _______________________________________________ Catalog-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
