[Distutils] funny looking download links (was: Automatically going for a pre-req dev)

[Phillip J. Eby]

At 06:16 PM 1/6/2006 -0800, Kevin Turner wrote:
>On Fri, 2006-01-06 at 20:18 -0500, Phillip J. Eby wrote:
> > At 05:08 PM 1/6/2006 -0800, Ben Bangert wrote:
> > >ns# easy_install -U python-openid
> > >Searching for python-openid
> > >Reading http://www.python.org/pypi/python-openid/
> > >Reading http://www.openidenabled.com/openid/libraries/python/
> > >Reading http://www.openidenabled.com/openid/libraries/python/
> > downloads/python-openid-1-0-3-tar.gz/download
> > >No local packages or download links found for python-openid
> > >error: Could not find distribution for Requirement.parse('python- openid')
> > >
> > >Apparently it doesn't like Plone download links?
> >
> > Yep.  Not very RESTful, that.  :) The second problem is that the filename
> > isn't a valid distutils source distro filename for a '1.0.3' version; the
> > name should be python-openid-1.0.3.tar.gz instead.
>
>Huh?  It's RESTful, you're just overly concerned with the syntax of the
>URL.

My point (such as it is) was that REST prefers to avoid putting verbs (e.g. 
download) in URLs.  There was also a ":)" to indicate that it was an 
attempt at humor.  :)


>First though, let me play devil's advocate for a moment here:  I entered
>this URL into the "download URL" field of a record that explicitly
>refers to the 1.0.3 version of this package.  Why not use it?

1. Because a significant % of the packages on PyPI have a download URL that 
points to an HTML page, which then (sometimes) has links to the actual 
downloadable packages.

2. Because easy_install needs to know what version of the package it's 
dealing with and what format, in order to select the appropriate 
package.  Since easy_install can collect data from various web pages in 
addition to what's on PyPI (as well as an arbitrary number of links found 
on a PyPI page), it needs a parseable filename.


>If you're worried about ending up with a file named "download" that you
>don't know how to unpack, the reasonable name
>(python-openid-1.0.3.tar.gz) is specified in the
>not-really-standard-but-well-documented Content-Disposition HTTP header.

The irony is that easy_install *is* downloading the file, but then ignores 
it because it's not an HTML page.  I suppose I could get it to sniff the 
content type and disposition, but in my experience so many servers have 
differently configured values for the content-type of .tar.gz files that 
there isn't anything particularly stable about content-type.  I suppose if 
the tool encounters a non-HTML page, I could have it try to interpret the 
suggested filename and pretend it got that information from the URL.  This 
would result in two downloads of the same file, of course, but if you want 
to avoid that, you can just use the #egg trick.

Anyway, even assuming I actually implement this, it'll take a while for 
everybody to update their setuptools such that they could actually use 
it.  In other words, you'll need the #egg trick for some time to come no 
matter what.


>(I'd bug the Zope guys about this, but I can see how it'd probably break
>their object publishing model to do it differently.  If I were lucky,
>they might give me
>http://www.openidenabled.com/openid/libraries/python/downloads/python-openid-1-0-3-tar.gz/download/python-openid-1.0.3.tar.gz 
>, and then I'd have to patch cheeseshop so that the overly long URL 
>wouldn't hose the page formatting any more than it already does...)

Just include the URL in your long_description field, and if you use reST 
(reStructured Text) you can give it a nice human-readable content that 
doesn't display the URL.  For an example, see 
http://cheeseshop.python.org/pypi/setuptools which has several links in the 
long_description, one of which is an #egg link for the SVN version.