Feature/record download info

[dstufft]

Adds a info.ini to the egg-info directory. This file is designed to serve as a repository of information about the installed package. Currently it only uses 1 section (download) and 2 keys under that section (url and requirement).

url gives the exact url that the package was installed from. In the case of a normal package it is a tarball, and in the case of an editable it is the vcs url.

requirement gives the (almost) exact line that was used to cause this package to install. I say almost because it doesn't capture if the user used -e vs --editable= but assumes --editable=

Some examples:

Tarball
# Passed a Tarball as the requirements line
[download]
url = http://packages.crate.io/f/6/f/e/f6feefb1a4e0573d4eccc9be0eb1384fac7e93db98b700da3e66c6d0a6eeb921/regex-0.1.20101123.tar.gz
requirement = http://packages.crate.io/f/6/f/e/f6feefb1a4e0573d4eccc9be0eb1384fac7e93db98b700da3e66c6d0a6eeb921/regex-0.1.20101123.tar.gz#sha256=f6feefb1a4e0573d4eccc9be0eb1384fac7e93db98b700da3e66c6d0a6eeb921

Editable
# Editable
[download]
url = git+git://github.com/django/django.git#egg=Django
requirement = --editable=git+git://github.com/django/django.git#egg=Django # <- This one isn't the exact line, however we know it was an editable so we jsut use --editable=%s

Name
# Just a Name (e.g. pip install certifi)
[download]
url = http://packages.crate.io/4/6/e/c/46ecf5f7526a08cc1f8bc8232adf0cffce046f46ceff95539daec42ebc4849ef/certifi- 0.0.8.tar.gz#sha256=46ecf5f7526a08cc1f8bc8232adf0cffce046f46ceff95539daec42ebc4849ef
requirement_line = certifi

Pinned
# Pinned
[download]
url = http://packages.crate.io/2/1/0/a/210a82e678c45d433a4ad1f105974b3102a8ab5198872dc0a3238a8750d4c65e/requests-0.10.0.tar.gz#sha256=210a82e678c45d433a4ad1f105974b3102a8ab5198872dc0a3238a8750d4c65e
requirement = requests==0.10.0

Test Information

Python2.4 : Unable to get it installed on OSX 10.7? Keeps throwing errors (python itself)

Python2.5 : Tests won't run on this, fails almost immediately.

Python2.6/develop : FAILED (failures=2)
Python2.6/feature/record-download-info : FAILED (failures=4)

Python2.7/develop : FAILED (failures=1, skipped=1)
Python2.7/feature/record-download-info : FAILED (failures=3, skipped=1)

Python3.1/develop : FAILED (failures=4, errors=2, skipped=2)
Python3.1/feature/record-download-info : FAILED (failures=68, errors=2, skipped=2)

Python3.2/develop : FAILED (failures=4, errors=2, skipped=2)
Python3.2/feature/record-download-info : FAILED (failures=68, errors=2, skipped=2)

The added failures all have to do with bundles, but I fear I don't understand the internals of pip well enough to figure out why they are occuring. Hopefully someone else can figure that out? I'll look into the 3.x failures (unless someone else does) but I wanted to submit this just to get eyes on the approach initially.

[carljm]

Wow, awesome. Thanks for all this work!

I think we should use a pip-specific name for the ini file, as we're dumping it in a metadata directory that other software (e.g. setuptools/distribute) reads as well. Maybe just "pip.ini".

Re tests, how do those failure numbers compare to what you get on stock develop branch?

[carljm]

Here you know the version of INITools, and you know the Python version, so you can construct the exact egg-info directory name, you don't have to go searching for it like this.

[carljm]

Looks very close, overall! It does appear that somehow this is breaking bundling, perhaps because building a bundle does something odd regarding egg-info dirs, not sure. We'll need to get that sorted out, I can look into it once the other comments are addressed.

[dstufft]

I'll get your comments addressed. Tonight maybe or tomorrow if I don't have time tonight.

I included the stock develop branch numbers for the tests as well in the original pull request (PythonVersion/BranchName). I was tired so I didn't start sorting out the 60ish additional errors I created on Python3.1 and Python3.2 yet. I need to figure out a place to run the tests on 2.4 still. Probably on my linux VPS. Ditto for 2.5 which was completely crapping out really early on in the test process (before tests was even being run).

[jterrace]

What's the status of this? It would be awesome if this could get merged.

[dstufft]

I've not had a lot of time, however another guy just recently messaged me as he's fixed up most of the failing tests he said.

[tgecho]

I think I have most of the outstanding issues worked out. I just need a bit of help with the bundling tests (or more time to grok them myself). New pull request over at #507.

[dstufft]

I'm going to close this as @tgecho's work in #507 has superseded this pull request.