3

I'm getting this error when recreating Pipfile.lock:

packaging.specifiers.InvalidSpecifier: Invalid specifier '==0.5.2-auto'

I think it has something to do with the -auto suffix, but it works on a different computer for some reason.

The traceback seems to be truncated for some reason, here's all I see in the console:

pipenv/vendor/requirementslib/models/requirements.py", line 1008, in get_version
    return parse_version(self.get_specifier().version)
  File "/home/johneye/.local/share/virtualenvs/python-microservice-scaffolding-ylP1urgf/lib/python3.6/site-packages/pipenv/vendor/requirementslib/models/requirements.py", line 1005, in get_specifier
    return Specifier(self.specifiers)
  File "/home/johneye/.local/share/virtualenvs/python-microservice-scaffolding-ylP1urgf/lib/python3.6/site-packages/pipenv/vendor/packaging/specifiers.py", line 85, in __init__
    raise InvalidSpecifier("Invalid specifier: '{0}'".format(spec))
packaging.specifiers.InvalidSpecifier: Invalid specifier '==0.5.2-auto'
JohnEye
  • 6,436
  • 4
  • 41
  • 67

1 Answers1

2

I'm posting a partial answer since I only got three results on Google when looking for the precise error message.

From looking at the code and modifying it, it became clear that there are at least two kinds of specifiers - a legacy specifier which could contain just about anything and a standard specifier, which conforms to PEP 440.

When the dependencies are being locked, the specifiers are checked against a regex to see if they are valid or not. I saw that they are sometimes being checked against the legacy specifier and sometimes against the normal one. At this point, I abandoned the search for the root cause and decided that it will be better to fix my code to conform to both specifiers, so I changed it to ==0.5.2-dev1, which fixed the problem.

JohnEye
  • 6,436
  • 4
  • 41
  • 67