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

Ian Bicking ianb at colorstudy.com
Thu Sep 24 21:37:19 CEST 2009


2009/9/13 Tarek Ziadé <ziade.tarek at gmail.com>

> 2009/9/13 "Martin v. Löwis" <martin at v.loewis.de>:
> >> $ easy_install hachoir-core
> >> Searching for hachoir-core
> >> Reading http://pypi.python.org/simple/hachoir-core/
> >> Reading http://hachoir.org/wiki/hachoir-core   <- this page doesn't
> >> exists anymore that's an old home url
> >>
> >>      page, you're blocked for a while !!
> >>
> >> If we keep this behavior, the client-side should be more smart.
> >
> > I disagree. It's the package maintainer's task to make sure the
> > published URLs actually work.
> >
>
> They do as a matter of fact. But once an url is published, it's
> published "forever".
>
> Take the hachoir-core as an example. The home URL was changed in
> 1.2.1 to :
>
> "http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
>
> the 1.2 version home url was:
>
> "http://bitbucket.org/haypo/hachoir/wiki/hachoir-core"
>
> But the PyPI simple API will keep track of both:
>
> http://pypi.python.org/simple/hachoir-core
>
> Leading to the problem described (because the script visits all urls
> before it decides
> what tarball to pick)
>
> So what the maintainer should do ?
>
> Recreate a new version of an old release so the old URL is removed
> from PyPI ? Just register the metadata, knowing that the one contained in
> the tarball is not the same ?
>
> I mean, if I change my home url at the 25th version of my distribution,
> I need to release again the 24 previous versions of the distribution ?
>

Another related problem is links like, say,
http://svn.colorstudy.com/virtualenv/trunk#egg=virtualenv-dev -- I have a
bunch of these links in old versions, I'd like to move the repository
somewhere else, and so of course update that link and magically everyone can
still install virtualenv==dev.  Except the link remains unless I edit all
old versions of the packages to change or remove that link.

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).


-- 
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/5f8cc8c2/attachment.htm>


More information about the Catalog-SIG mailing list