Unnamed editable dependency raises AttributeError on second run

[genericmoniker]

An editable dependency without a name raises an AttributeError when pip-compile is run the second time without the --upgrade flag.

Environment Versions

1. CentOS 7
2. Python version: Python 3.5.2
3. pip version: pip 9.0.1
4. pip-tools version: pip-compile, version 1.8.1

Steps to replicate

foo.in:

-e .

run:

pip-compile foo.in
pip-compile foo.in

Expected result

#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile --output-file foo.txt foo.in
#
-e file:///home/eric/projects/foo

(Well, not really the hoped for result due to #204.)

Actual result

Traceback (most recent call last):
  File "/home/eric/projects/foo/.env/bin/pip-compile", line 11, in <module>
    sys.exit(cli())
  File "/home/eric/projects/foo/.env/lib64/python3.5/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/eric/projects/foo/.env/lib64/python3.5/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/eric/projects/foo/.env/lib64/python3.5/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/eric/projects/foo/.env/lib64/python3.5/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/eric/projects/foo/.env/lib64/python3.5/site-packages/piptools/scripts/compile.py", line 139, in cli
    key = key_from_req(ireq.req)
  File "/home/eric/projects/foo/.env/lib64/python3.5/site-packages/piptools/utils.py", line 41, in key_from_req
    key = req.name
AttributeError: 'NoneType' object has no attribute 'name'

I think this could be fixed in compile.py (around line 138) by waiting to see if is_pinned_requirement returns True before trying to get the key. Something like...

        for ireq in ireqs:

            if is_pinned_requirement(ireq):
                key = key_from_req(ireq.req)
                existing_pins[key] = ireq

[davidovich]

Thanks I have reproduced. It only happens on second compile run, when an output requirement already exists.