pip 24.2 pip check - package is not supported on this platform
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 01 Oct 2024 08:00:07 UTC
Hi all, There is a problem with the `pip check` command when running pip 24.2 and later on FreeBSD. I hope this is the right place to raise it. With pip version 24.2 and later, if a FreeBSD security update has been applied since packages were last installed, running `pip check` fails with errors that look like this: $ pip check xattr 1.1.0 is not supported on this platform psutil 6.0.0 is not supported on this platform PyYAML 6.0.2 is not supported on this platform coverage 7.6.1 is not supported on this platform cffi 1.17.1 is not supported on this platform MarkupSafe 2.1.5 is not supported on this platform This has started occurring because the pip check command was recently made more strict. [1][2][3] It now checks that the tags listed in the installed packages' WHEEL files match the OS. For packages that have ABI dependencies, these tags include the full OS release information, including the patch number. For example: Tag: cp311-cp311-freebsd_14_1_release_p4_amd64 This string looks to have been built from the output of `uname -mrs`, which might not be a bad way of identifying the ABI on other OSes, but it’s fragile on FreeBSD. Most other OSes don’t include patch numbers in the output of `uname -r`, so this string doesn’t change nearly as often for them. I think it would be good if the patch number could be filtered out somehow when building this string on FreeBSD. The packaging documentation [4] seems to suggest that it comes from sysconfig.get_platform(), which currently returns 'freebsd-14.1-RELEASE-p4-amd64’. So if that string could be filtered before it’s written out to tags in WHEEL files, and pip could have the same change made to its understanding of the current environment when checking tags, that would fix this issue for all packages installed in future. Existing installed packages with patch numbers in their WHEEL files would still need to be reinstalled, but that seems to be necessary anyway to work around this issue as things stand. I’m not familiar enough with the pip or python packaging source code to be able to suggest code patches, but I’m hoping that the above information might be helpful to someone who is. Thanks in advance, Sam [1] https://ichard26.github.io/blog/2024/08/whats-new-in-pip-24.2/#pip-check-just-got-a-bit-stricter [2] https://github.com/pypa/pip/pull/11088 [3] https://github.com/pypa/pip/commit/db062e8574ee78fc7a61ec3aff070395dec409ff#diff-f38594dcdb284279fd0fb84ffc243fb2231337517f4b3ad572bd1ae809ecb524R7 [4] https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/#platform-tag