At 07:54 AM 2/28/2008 +1100, Richard Jones wrote: >On Thu, 28 Feb 2008, Phillip J. Eby wrote: > > One minor possible hurdle is that package_releases() doesn't list > > *all* available versions, only the "unhidden" ones. It might be nice > > to have a separate API to request *all* versions. > >Done. package_relases now takes (package_name, show_hidden=False) - setting >show_hidden to True will make it list all versions, hidden or not. > > > > OTOH, I have to say that the availability of the new "simple" API > > makes it a lot more tempting to just use that. Because there, I can > > make just *one* server round trip to get all the data I need, > > assuming that the user has properly spelled and capitalized the > > package name. Whereas, with the XML-RPC API, it requires a minimum > > of two calls. > >Unless we write a new call ... what_setuptools_needs(package_name) which does >a search on the name, then case-insensitive if that fails and returns the egg >URLs.
Or you could just make it so that release_urls() doesn't need a second argument, and if omitted, returns a dictionary of all versions' download information. That would make it single-roundtrip in the case where somebody spells the name correctly and case-matched. By the way, speaking of name matching, was there ever a decision reached about name canonicalization for PyPI? (i.e., disallowing registration of packages that have identical names except for case or punctuation?) > > (And of course, the "simple" API can be statically > > mirrored, while XML-RPC cannot.) > >Yep. Right - so I don't really see what the benefit of using the XML-RPC here is. If the people who are maintaining PyPI really want that, I guess we could do it. But ISTM that since the "simple" API is already officially supported and widely used/tested, scaling up the load on XML-RPC might actually be a bad idea, from a "keeping PyPI running" point of view. And of course, it's another API. Besides, aren't REST APIs all the rage these days, anyway? XML-RPC is like, soooo 2003. ;-) _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
