>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. _______________________________________________ Catalog-sig mailing list Catalog-sig@python.org http://mail.python.org/mailman/listinfo/catalog-sig
