On Tue, Feb 28, 2012 at 2:35 PM, Richard Jones <[email protected]> wrote: > On 28 February 2012 22:07, anatoly techtonik <[email protected]> wrote: >> On Sun, Feb 19, 2012 at 12:07 AM, Donald Stufft <[email protected]> >> wrote: >>> On Saturday, February 18, 2012 at 4:01 PM, anatoly techtonik wrote: >>> 1. does anybody else also thinks that having a way to list all package >>> versions available on PyPI would be awesome? >>> >>> It's possible via the API to list all packages regardless of hidden or not. >>> The Web UI doesn't support it. I'm assuming from the ticket PyPI is happy >>> with the way it works, but fwiw you can see all the package versions for >>> Sphinx at http://crate.io/packages/Sphinx/ (click the All Versions tab). >> >> Thanks for replies about API, I used XML-RPC myself, but it's not a >> good user experience to require Python shell to get information from >> the web site. http://pypi.python.org/packages/source/S/Sphinx/ really >> helps to see what packages are available using browser alone, but >> unfortunately it is a hidden magic. > > When PyPI was created there was a design discussion and decision made > that the site implement the most common case which is that package > authors expose only one version, the most recent one. Unsupported > versions are deliberately difficult to find. That's the point. The > intention is to reduce the authors' maintenance burden by discouraging > people from using older versions of their software. > > Your example project, Sphinx, advertises precisely one current > version, 1.1.2. This is the one on their website and it's the one on > PyPI. > > Some packages expose more versions because they have multiple release > branches and that's their choice. More versions are findable on the > site for those packages. > > And, as has been pointed out, for data mining applications you can get > access to the full data. > > > Richard
Thanks for the proper explanation. At last, after 11 days and catalog-sig subscription. =) This proves that SF tracker is useless and fails to communicate with users. It would be interesting to glimpse at the archives of this design discussion. I can not agree that users should be deliberately limited. -- anatoly t. _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
