Pip-tools: Error on 3.5.1 and latest pip

[nikolay]

$ pip-compile
Traceback (most recent call last):
  File "~/pyenv/versions/wp-scripts/bin/pip-compile", line 11, in <module>
    sys.exit(cli())
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/click/core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/piptools/scripts/compile.py", line 127, in cli
    if is_pinned_requirement(ireq):
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/piptools/utils.py", line 75, in is_pinned_requirement
    if len(ireq.specifier._specs) != 1:
  File "~/pyenv/versions/3.5.1/envs/wp-scripts/lib/python3.5/site-packages/pip/req/req_install.py", line 286, in specifier
    return self.req.specifier
AttributeError: 'NoneType' object has no attribute 'specifier'

[akx]

(Found this via the HN thread.)

I'm unable to reproduce this with a minimal test case:

$ python -v
Python 3.5.1
$ pip install -U pip
Successfully installed pip-8.1.0
$ pip install pip-tools
Successfully installed click-6.3 first-2.0.1 pip-tools-1.6 six-1.10.0
$ echo "Django" > requirements.in
$ pip-compile requirements.in
#
# This file is autogenerated by pip-compile
# Make changes in requirements.in, then run this to update:
#
#    pip-compile requirements.in
#
Django==1.9.4

Can you post a script/test case which _does_ repro this?

[mkleehammer]

I found the same error and it has to do with the contents of my existing requirements.txt. I found this out when I tried to reproduce it for you and found that it doesn't fail if I copy the file to a different name - the output file doesn't exist in that case.

The line that causes the error is:

git+https://github.com/mkleehammer/sourcemap#1.0.1

This is a module I needed that isn't done well enough to put on pypi. I have not yet looked into making this work with pip-compile, so any insights into this would be good too.

[akx]

@mkleehammer I think that should be @1.0.1 (if there is a tag called 1.0.1), or #egg=sourcemap==1.0.1 (to tag an arbitrary URL as referring to a certain version). Would that make it work?

[nikolay]

Any update?

[jerzyk]

Shoudn't you have "-e " in front and "@" as version separation?

[The-Compiler]

FWIW I see the same with -e ./scripts/dev/pylint_checkers (with that being a local path in my repo)

[vphilippon]

This seems to be related to an issue with paths/links when they appeared in the output file (i.e. requirements.txt). That was fixed by PR #485, which was merged in master.
Could you try on your side and confirm if it fixed your use case?
Thanks!

[davidovich]

closing, please reopen if it is still an issue.

[staring-frog]

Just in case someone else runs into this, I was getting this traceback with my requirements.txt having a line like

../somepackage

Removing it helped.

[alevikpes]

I still have this problem. Even for the simplest case mentioned here (with a single Django package). What was the solution?

[alevikpes]

ok, found it. This happened to me, when the requirements.txt existed already. I was expecting it to be overwritten. After I removed it, I got an error: piptools.exceptions.UnsupportedConstraint: pip-compile does not support URLs as packages, unless they are editable. Perhaps add -e option? (constraint was: git+ssh://[email protected]/back-end/custom-package.git@latest (from -r requirements.in (line 45))). It was working fine after I removed the offensive line. But I would expect these kinds of links to be handled - I do not want the package to be editable.

For the rest, it is a nice tool. Thanks.

[vphilippon]

@AlexandrPy Good to hear you got this fixed.
So for anyone else stumbling on this: Be sure to check your existing requirements.txt for any non-editable URLs.