[Catalog-sig] simple index and urls exracted from metadata text fields

Ian Bicking ianb at colorstudy.com
Thu Sep 24 22:28:30 CEST 2009


2009/9/24 "Martin v. Löwis" <martin at v.loewis.de>

> > Is there a reason the simple version of the API needs to include links
> > from the descriptions of any old versions of the package?  Eliminating
> > links from all old/hidden package descriptions would I think solve this
> > (except for links explicitly for downloads, which are generally
> > versioned and okay).
>
> They are included because Jim Fulton said they ought to be included.
> More precisely, the spec for the simple API was this:
> - place all links on a single page, for all versions, to reduce the
> number of roundtrips
> - per version, include the links from the metadata, plus any links from
> the description.
>
> I'm not sure what would break if I change not, nor do I understand what
> "#egg=virtualenv-dev" does.
>

It tells easy_install (and pip) that the URL points to a location that
contains the virtualenv package, version "dev".  For most tarballs, the URL
of the tarball can be parsed to get the package and version number, but this
isn't the case for repositories (or things like a tarball created on demand,
like you get from most hg and git repositories).


> I fail to see your problem, though: if you move the source repository
> to a different URL, and just break the old URLs to return an HTTP error,
> wouldn't that be sufficient?
>

I'm pretty sure something like this is happening:

versions = {}
for url, version in find_all_the_links():
    versions[version] = url

So it's just wiping over the new URL with the old one.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |
http://topplabs.org/civichacker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20090924/13ffd5bd/attachment.htm>


More information about the Catalog-SIG mailing list