[Catalog-sig] PyPI update broke setuptools

[Phillip J. Eby]

>Sorry, this didn't register when you first posted. You were relying on a
>side-effect that I removed while we were trying to remove the "pypi" part of
>the URL. It seemed wrong to me that PyPI would return totally different
>results for:
>
>     http://cheeseshop.python.org/pypi
>     http://cheeseshop.python.org/pypi/

Well, it seemed quite *right* to me, with "pypi" being the front page, and 
pypi/ being the directory listing of packages.  It fit perfectly with the 
rest of the URL scheme, and so I assumed it was an intentional feature, not 
just a desirable one.  :)


>Is there any chance the software could be changed to use the more correct
>"?:action=search" which is what the "/" side-effect was effectively doing?

Certainly it could be changed, but because the PyPI change breaks the 
versions that are already in the field, it would require a new release, 
which would be rather awkward at the moment, because I don't want to force 
people to upgrade to the heavily refactored 0.6 series from the relatively 
stable 0.5 series.  I was planning to make a release of 0.6a1 this coming 
weekend, but not upgrade ez_setup, so that people would need to make a 
conscious decision to upgrade.  Thus, I'm somewhat loathe to put an 
upgraded version into wide release in order to fix an unrelated problem.

Also, the reason I didn't use the uglier search API in the first place was 
because the more REST-like interface using a / seemed more compatible with 
manually-created catalogs.  i.e., somebody can simulate a catalog of their 
own just by using static files and directories, whereas the :action=search 
thing is pretty heavily tied to a single protocol version of PyPI and 
requires the index to be implemented using some kind of dynamic 
technology.  I deliberately wanted to make EasyInstall's protocol 
expectations modest enough that a wide variety of technologies could 
fulfill them, so as to allow for small private or specialty indexes to 
exist without needing to set up databases and such running the same 
software as PyPI.

PyPI's existing URL-based API (including the '/' trick) seemed *perfect* 
for this, and both python.org/pypi and cheeseshop.python.org/ seemed to 
obey it.

If the software has to change, it has to change.  But I'd much prefer it if 
we could restore service to existing versions of the software, and it would 
also be nice if I could continue to allow people to create interoperable 
indexes based on static files, without EasyInstall having to do more 
sophisticated (and therefore more fragile) sniffing to tell what version of 
PyPI (or not) it's running against, or having to introduce command line 
options to tell EasyInstall what PyPI protocol version to use, or whatever.