At 01:55 PM 1/6/2006 -0800, Ben Bangert wrote:

When installing a package that requires the dev version of another package, it fails to to and download a dev version of the package. This appears to be because it either searches the filesystem for the prereq version, or asks CheeseShop.

Given that the prereq indicates it wants a dev version, it would seem reasonable to search CheeseShop with ==dev equivalent active.

As an example, if you install: easy_install -U hellahella==dev

It installs fine from svn, then goes back searching for Pylons, and gets: Processing dependencies for hellahella==0.1dev-r576 Searching for Pylons>=0.1dev-r289 Reading http://www.python.org/pypi/Pylons/ Reading http://pylons.groovie.org/ No local packages or download links found for Pylons>=0.1dev-r289 error: Could not find distribution for Requirement.parse ('Pylons>=0.1dev-r289')

Yet, if you run: easy_install -U Pylons==dev

It has no problem fetching the latest Pylons and the Paste prereqs (which would have the same problem if I hadn't linked to them explicitly on the Pylons page).

Since you already indicate you want ==dev, shouldn't it keep that during the prereq if necessary?

There is nothing special about 'dev' as a version; it could be "Pylons=any_old_version" for all easy_install knows. What you want is to set your install_requires=['Pylons==dev,>=0.1dev-r289'] instead. This tells easy_install that if it sees a link to a 'dev' version, go ahead and install it, but at runtime the distribution will have to match the other version, because there is really no "dev" version. Which is why the trick works, basically. If you ask for ==dev *or* >=0.1dev-r289, the latter will not be found on the Cheeseshop (until an 0.1 final is released), but a link to the "dev" version will. At runtime, nothing matches "dev", but it *will* match the 0.1dev. Anyway, this trick could be played with any special version in place of "dev", but that is currently the convention being used by most people posting links to SVN versions. It's the responsibility of the person defining the dependencies to say whether they want development versions of their requirements.

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. You can work around both of these issues by adding '#egg=python-openid-1.0.3' to the end of the download URL on your PyPI page, which explicitly tells easy_install how to interpret the link. Note, however, that #egg link fragments are intended mainly for Subversion checkouts, and easy_install will therefore give a higher match precedence to any binary links that match, *including* any .tar.gz or other archive links that don't use #egg. (Unless the user requests an --editable checkout, in which case #egg links and source distributions have the highest priority.) Anyway, it's probably better in the long run to simply make files available with the standard distutils filename, and use #egg in this case only as a workaround.

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