easy_installability of older bzr releases.

[Wouter van Heyst]

replying to my own post to follow up on things I'd look into.

On Fri, May 01, 2009 at 08:32:06PM +0200, Wouter van Heyst wrote:
> On Fri, May 01, 2009 at 11:05:48AM +1000, Martin Pool wrote:
> > 2009/5/1 Wouter van Heyst <larstiq at larstiq.dyndns.org>:
> > > I see 4 possible solutions:
> > >
> > >    1) attach files to every release on pypi we still care about

This can be done with `python setup.py sdist upload`, something we might
want to consider including in the release process. Except we don't use
sdist at the moment, and I haven't found a way to make upload work with
a tarball of our choosing.

> > >    2) change the release process to have setup.py download location
> > >        point at a specific to that release location
> > >    3) change (or add to) the general download url to
> > >        https://edge.launchpad.net/bzr/+download
        
Afaics, it is not possible to have more than 1 download_url. So it is
either http://bazaar-vcs.org/Download _or_ https://launchpad.net/bzr/+download
The latter is fine for machines, but not too nice for humans.

> > >    4) change http://bazaar-vcs.org/Download to include links for older
> > >        releases

> > So easy_install scans through the html of the download page to try to
> > find the right file?  How clever.

Specifically, it constructs a setuptools.package_index.PackageIndex to
go through the links in http://pypi.python.org/pypi/bzr/ (which includes
all homepage/download_url items from all releases, as well as all hrefs
from the long_description), and applies a regex to match the version
requested.

> > I like the sound of #3 more.  If the metadata is intended to point to
> > a place where all old releases can be obtained then doing so in a way
> > that works for machines but not for people would be a bit weird.

#3 would mean working for machines, but not for people imo. Whereas
people can follow an extra level of indirection from /Download, and
machines can parse #4.  So that is what I'll be going to do, in lieu of
#1 it is the only workable option I see.
 
> I don't know if pypi supports two download urls, that would be good to
> test.  If it doesn't, do we want to forego our Downloads page in favour
> of the launchpad listing?  I wouldn't at the moment, which is why I
> favour 4).

Pypi doesn't support more than one download_url as I said, we can still
consider changing it for older versions.

> People unlike easy_install can follow an additional level of indirection
> to get at the older releases.  Maybe I should check easy_install can't
> do that.

The mechanisms easy_install uses to find package indices don't allow us
to give it another index with the data out there, alas.

Wouter van Heyst