[Catalog-sig] Prototype setuptools-specific PyPI index.
Phillip J. Eby
pje at telecommunity.com
Sat Jul 21 21:51:26 CEST 2007
At 09:23 PM 7/21/2007 +0200, Martin v. Löwis wrote:
> > Unfortunately, that doesn't help current versions of setuptools. See
> > point #7 of:
> > http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
> > Setuptools looks for release links, not package links on that page.
>I don't understand. What's a "release link"? The links on the index
>page *do* go to the "project's active version pages", as specified
>(there aren't any numbered version pages)
See point #2:
"""2. Individual project version pages' URLs must be of the form
base/projectname/version, where base is the package index's base URL."""
That's what's meant by "version pages" in point #7 -- i.e., they
*must* be of that two-part form for setuptools to recognize them as such.
>I see that it doesn't work, but I cannot understand why.
>"pywin32" is clearly linked, so it should be able to resolve
It could perhaps be *changed* to do so, but at present it follows the
spec's definition of "version page" URLs.
> > Jim's already mentioned these, but the rel="" info (per the index API
> > spec's point #6),
>This is fixed.
Great; Sourceforge and other offsite download pages work now.
> > and the links embedded in the long_description field
> > (per point #4) are missing.
>I have to think about this more. Is it correct that you want all href
>attributes of all a elements in the long_description?
Yes; of course, the usual rendering needs to be applied, since
long_description can contain reStructuredText.
> And how do you
>know what the long_description is from just looking at the rendered
You don't need to; easy_install discovers those links the same way it
does any other Cheeseshop-provided download links. From
easy_install's point of view, the entire page is just one big mass of
links that might point to downloads:
"""4. ...It is explicitly permitted for a project's
"long_description" to include URLs, and these should be formatted as
HTML links by the package index, as EasyInstall does *no special
processing* [emph. added] to identify what parts of a page are
index-specific and which are part of the project's supplied description."""
In other words, the *only* links that are specially handled are the
"rel" ones, which it follows unconditionally to look for additional
direct download links. All other links are merely *inspected* to see
if they obviously refer to a downloadable package (e.g. .tgz, .zip,
.egg, .exe etc., or explicitly-marked #egg). As a side-effect, this
means that links to perform Cheeseshop operations, links to other
parts of python.org, etc. are simply ignored, as they are not links
to downloadables nor marked as #egg.
If a URL can be determined by inspection to be a download link, then
easy_install extracts version and platform info from the URL and adds
it as a candidate for download selection. When both the home page
and download URL have been read, along with any detected "active
version pages" (as defined above), then easy_install chooses the
"best" download URL from all the candidates it has seen up to that point.
More information about the Catalog-SIG