pdm add fails with.: packaging.specifiers.InvalidSpecifier: Invalid specifier: '>=0.1.dev126+gaeebca2'

[franzhaas]

Dear all,

On one of our machines installing one of our internally created wheels, which use git hashes as part of their version information fails with this error message.:

packaging.specifiers.InvalidSpecifier: Invalid specifier: '>=0.1.dev126+gaeebca2'

The output of pipx runpip pdm list ist.:

C:\test\pdmtest2>pipx runpip pdm list
Package Version

---

blinker 1.5
CacheControl 0.12.11
certifi 2022.12.7
charset-normalizer 2.1.1
commonmark 0.9.1
distlib 0.3.6
filelock 3.8.2
findpython 0.2.2
idna 3.4
importlib-metadata 5.1.0
installer 0.6.0
lockfile 0.12.2
msgpack 1.0.4
packaging 22.0
pdm 2.3.2
pip 22.3.1
platformdirs 2.6.0
Pygments 2.13.0
pyproject_hooks 1.0.0
python-dotenv 0.21.0
requests 2.28.1
requests-toolbelt 0.10.1
resolvelib 0.9.0
rich 12.6.0
setuptools 65.6.3
shellingham 1.5.0
tomli 2.0.1
tomlkit 0.11.6
unearth 0.6.3
urllib3 1.26.13
virtualenv 20.17.1
wheel 0.38.4
zipp 3.11.0

After downgrading packaging to version 21.3 using.:

pipx runpip pdm install packaging==21.3

It works for me. I don't think this is a pdm bug, although a addition to the dependencies to avoid this version would be nice.
I mainly put it here, to help others with the same issue.

thanks,
Franz

[franzhaas]

This is propably a duplicate to this.: pypa/packaging#629

[pradyunsg]

That issue is about a discrepancy between Requirement and Specifier in that package's API; the InvalidSpecifier error is related to PEP 508/440 and packaging becoming strict around that.

[franzhaas]

I am sorry can you elaborate on that?
Does this mean we need to change the way we version our wheels?
Does this mean I linked to an unrelated issue?

[pradyunsg]

Does this mean we need to change the way we version our wheels?

I have not looked closely but this might be the case. Try doing import packaging.version as v; v.Version(“your version here”). If it doesn’t raise an error, then those versions are OK. If it does, then they’re not OK.

Does this mean I linked to an unrelated issue?

Yes, that’s what I was trying to say. Thanks for probing and sorry for not being clear.

[franzhaas]

Thanks a lot for the clarification. I tried your suggestion, and as far as I can tell, versions create by setuptools using scm versions with git are ok.

In [1]: import packaging.version as v; In [2]: import packaging.version as v; v.Version("0.1.dev126+gaeebca2") Out[2]:

In [3]: import packaging

In [4]: packaging.version
Out[4]: '22.0'


[pradyunsg]

❯ python -c 'import packaging; print(packaging.__version__); import packaging.specifiers as s; print(vars(s.SpecifierSet("==0.1.dev126+gaeebca2")))'
22.0
{'_specs': frozenset({<Specifier('==0.1.dev126+gaeebca2')>}), '_prereleases': None}
❯ python -c 'import packaging; print(packaging.__version__); import packaging.specifiers as s; print(vars(s.SpecifierSet(">=0.1.dev126+gaeebca2")))'
22.0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/venv/lib/python3.10/site-packages/packaging/specifiers.py", line 700, in __init__
    parsed.add(Specifier(specifier))
  File "/tmp/venv/lib/python3.10/site-packages/packaging/specifiers.py", line 234, in __init__
    raise InvalidSpecifier(f"Invalid specifier: '{spec}'")
packaging.specifiers.InvalidSpecifier: Invalid specifier: '>=0.1.dev126+gaeebca2'
❯ python -c 'import packaging; print(packaging.__version__); import packaging.specifiers as s; print(vars(s.SpecifierSet(">=0.1.dev126+gaeebca2")))'
21.3
{'_specs': frozenset({<LegacySpecifier('>=0.1.dev126+gaeebca2')>}), '_prereleases': None}
❯ python -c 'import packaging; print(packaging.__version__); import packaging.specifiers as s; print(vars(s.SpecifierSet("==0.1.dev126+gaeebca2")))'
21.3
{'_specs': frozenset({<Specifier('==0.1.dev126+gaeebca2')>}), '_prereleases': None}

Hmm... This is an interesting one. I'm guessing this is a legitimate bug in packaging but unrelated to any of the bugs reported so far. :)

[pradyunsg]

My suggestion to you, should you wish to work around this, is to drop +... in the comparision. That's what's causing the issue here with InvalidSpecifier in this case.

[pradyunsg]

I've filed pypa/packaging#637 on packaging's end to look into this.

[franzhaas]

My suggestion to you, should you wish to work around this, is to drop +... in the comparision. That's what's causing the issue here with InvalidSpecifier in this case.

Thanks a lot. What I am doing right now is downgrading packaging to 21.3, and so far I am happy with it.

I like the part after the + and hope that this functionality will be seen as a feature not as a bug... if it is declared to be a bug, i am confident that we can find a solution.

[pradyunsg]

OK, based on the discussion in that issue, the current behaviour is the intended behaviour.

[franzhaas]

OK, if I understand this thread correctly, the part after the + is acceptable in the lock file but not in the pyproject.toml.

I did not add this dependency by editing pyproject.toml but by using

pdm add locallyversionedpackage

So I believe the right thing to do would be to change pdm add to not add the local version part to the pyproject.toml.

[frostming]

Thanks for the clarification, I've created #1566 to fix it. PDM will not generate specifiers like >={version}+{local}, but if the package metadata contains such version specifiers, it will still fail.

[franzhaas]

Thanks a lot!