> 1. Access to "hidden" packages' release info Can you explain what you need them for, and when?
I don't fully understand _pypi_hidden, however, I thought that a "hidden" release is really one that the author doesn't want to be ever found, and that is maintained just because of old clients know exactly where it is, and access it directly. > 2. Links in the long_description that are rendered by PyPI's web interface Just specify precisely what operation you want, and what precisely the result should be, and it will appear (also for _pypi_hidden). > With this information, easy_install could be changed to use the XML-RPC > API.... *but* it would make even *more* round-trips to PyPI than it > does now, unless those APIs were also designed differently than the ones > that exist now, because you would need at least one search to find the > correct package and its PKG-INFO, and another search to get the download > files. Currently, it can at least get both of these in one trip, if the > package name is an exact match. Ok, so can you design different APIs, reducing the number of roundtrips to one in the common case, while simultaneously not requiring the server to compute information that is not needed in the common case? If you can, it will appear. > To answer Martin's question of why setuptools doesn't "trust" the PyPI > specification even more, it's because having chosen to use the web > interface to get the information, I thought it prudent to use only that > subset of the web interface that could be easily duplicated using simple > Apache directory indexes, since that meant someone could create their > own index or mirror a portion of PyPI without having to implement its > entire feature set. This later proved prudent when Jim wanted to have > tests of his buildout framework that did not rely on PyPI being up, as > it made it easier to create a mock PyPI for unit testing purposes. I still don't understand. I'm talking about not accessing all versions in /root/package/version, trusting that the last part really is a version (i.e. reading only /root/package, finding out all possible versions, selecting the best one, then reading /root/package/bestversion). I cannot see why this is unavailable in a straight directory indexes. Correct me if I'm wrong, but I think you can have /root/package/index.html /root/package/version/index.html and then still chose to make both index.html the same (if there is only a single version), or list the individual versions in the top-level index.html. Or, you can just drop /root/package/index.html, trusting that the Apache directory index will list the single version subdirectory, anyway. Regards, Martin _______________________________________________ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
