pip fails in GitHub action with Invalid version (image name!) #12825
Labels
project: vendored dependency
Related to a vendored dependency
type: bug
A confirmed bug or unintended behavior
type: support
User Support
Comments
MAKOMO
added
S: needs triage
|
You've set up Python 3.12, and have then tried to install deps that are pinned to earlier versions of Python, as old as Python 3.7. Please close this issue. |
notatallshaw
added
type: support
|
Those packages are not installed and should be ignored by pip as the conditions are not fulfilled. This requirement file is also used to make builds for platforms using older Python version. All packages that are actually installed are work fine on Python 3.12. Those messages are just warnings, right? the relevant part of requirements.txt reads like Something is broken with pip > 24.0 as up to 24.0 those GitHub actions were running just fine. |
|
From the stack trace it looks like you are using the legacy resolver, which is likely enabled in one of your requirements files. The new error reporting for invalid requirements has not been tested with it. I'd recommend trying with the standard resolver, and if that is not possible, stick with pip 24.0. |
|
Hm. I tried with the legacy resolver, but that did not help a thing. Here is the GitHub workflow which fails once pip is not pinned to 24.0, but using the one installed by default (v24.1) or and upgraded one (v24.1.1). The two requirements files are Is there a thing I can do to help investigating this one? I could remove that pip pinning again produce a full log of the action if that helps. |
|
The error you get with the standard resolver may give a clue. Feel free to post it, I'll have a look. |
|
Full log of the failed run not pining pip to v24.0: |
|
Adding the pin back I get (still running) |
|
Ah. This looks like pypa/packaging#774. |
notatallshaw
added
the
project: vendored dependency
|
Ah yes Marko you're right - I apologise. The deps are all well pinned, so the resolver shouldn't have to do too much. I ran pip install --dry-run locally and couldn't spot any problems, and the mind boggles as to where the image tag has come from in that f-string. I've reproduced it minimally, and it's just as you say: https://github.com/JamesParrott/artisan-roaster-bug/actions/runs/9813073537 |
Upps. This one is open since Jan. Hm. |
|
Yep, we need an upstream fix. In pip we can improve the error handling, though. |
|
Is there a way for me to find out wihch package is causing the troubles. Maybe I can convince the author make some adjustments... |
|
Now I get the following and my action runs as expected. Very good work! The problematic package is yoctopuce and I have already a good connection to them. I will inform them on the issue and try to convince them to improve on this. Hope your change will make it into the next pip release! Thanks a lot for your support, https://github.com/artisan-roaster-scope/artisan/actions/runs/9821072883 |
|
Well, actually the run is not completing as not all imports succeed. So I pin back to pip 24.0 and hope for an updated yoctopuce package. |
|
For what it's worth, AFAIU, this isn't a problem with the packages and it's not something they should need to work around either. The root problem seems to be that >>> m = Marker('platform_release >= "20.0-INVALID"')
>>> m.evaluate({'platform_release': '6.7.0-gentoo'})
True>>> m = Marker('platform_release >= "20.0"')
>>> m.evaluate({'platform_release': '6.7.0-gentoo'})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/ichard26/dev/oss/packaging/src/packaging/markers.py", line 325, in evaluate
return _evaluate_markers(self._markers, current_environment)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/ichard26/dev/oss/packaging/src/packaging/markers.py", line 225, in _evaluate_markers
groups[-1].append(_eval_op(lhs_value, op, rhs_value))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/ichard26/dev/oss/packaging/src/packaging/markers.py", line 183, in _eval_op
return spec.contains(lhs, prereleases=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/ichard26/dev/oss/packaging/src/packaging/specifiers.py", line 552, in contains
normalized_item = _coerce_version(item)
^^^^^^^^^^^^^^^^^^^^^
File "/home/ichard26/dev/oss/packaging/src/packaging/specifiers.py", line 28, in _coerce_version
version = Version(version)
^^^^^^^^^^^^^^^^
File "/home/ichard26/dev/oss/packaging/src/packaging/version.py", line 202, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
packaging.version.InvalidVersion: Invalid version: '6.7.0-gentoo'Due to how markers are commonly written, the left side is typically derived from the currently running environment, not the package. While a package could work around this bug by declaring an invalid version specifier, that seems unideal... I've filed pypa/packaging#816 in the hopes of fixing this upstream. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
Not an expert on anything, but my GitHub actions stop failing with pip 24.1 and 24.1.1
the error is reported like this:
It remains unclear which version and of which package is wrong here (not sticking to the semantic versioning rules?), so I was searching for the string '6.5.0-1022-azure' and could find that one as the image name of the VirtualMachine.
pining pip version to 24.0 before the installs resolves this:
Now it states:
reporting the issue is indeed in the "(image name!)" and those pip installs work.
Does the GitHub action image needs to stick to the Python/pip semantic versioning rules as well?
Expected behavior
ignore the image version and just sucessfuly complete
pip version
24.1.0 and 24.1.1
Python version
Python 3.12 and 3.11 (maybe independent of the Python version)
OS
Ubuntu
How to Reproduce
Output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: