[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