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