peep crashes when deps are already in the virtual env

[lonnen]

I had a requirements file with a single requirement. The package was already installed in my virtual environment, but I wanted peep to give me the sha to put in the file.

It appears that peep errors when the package is already installed into the virtual env because it never downloads files to hash.

console log of the problem with description:
https://gist.github.com/lonnen/c5dc13deb12589f6de04

[gsathya]

Thoughts on gsathya@859430e ?

(env)peep git:(master) : cat ../env/requirements.txt 
peep                                                                                                                                                                                          �
(env)peep git:(master) : python peep.py install -r ../env/requirements.txt

The following packages had no hashes specified in the requirements file, which
leaves them open to tampering. Vet these packages to your satisfaction, then
add these "sha256" lines like so:

Traceback (most recent call last):
  File "peep.py", line 379, in <module>
    exit(main())
  File "peep.py", line 371, in main
    return commands[argv[1]](argv[2:])
  File "peep.py", line 344, in peep_install
    print '# sha256: %s' % downloaded_hashes[package_name]
KeyError: 'peep'

becomes

(env)peep git:(bug22) : python peep.py install -r ../env/requirements.txt
These packages were already installed, so we didn't need to download or build
them again. If you installed them with peep in the first place, you should be
safe. If not, uninstall them, then re-attempt your install with peep.
    peep

[gsathya]

Sort of nitpick, but it makes more sense to make satisfied_req_names a dict, rather than a set if you're just doing lookup. The running time is O(n) and not O(n*n)

[gsathya]

Oh wow. Disregard my earlier comment. TIL python sets are implemented using dictionaries[0]

[0] - http://svn.python.org/projects/python/trunk/Objects/setobject.c

[erikrose]

Yep, they're dicts without values, iirc.