Date: Tue, 1 Oct 2024 18:00:07 +1000 From: Sam Vaughan <samjvaughan@gmail.com> To: freebsd-python@freebsd.org Subject: pip 24.2 pip check - package is not supported on this platform Message-ID: <10FABC99-E00A-4175-9B50-362FD6FDD96F@gmail.com>
next in thread | raw e-mail | index | archive | help
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=E2=80=99s fragile on FreeBSD. Most other OSes don=E2=80=99t include = patch numbers in the output of `uname -r`, so this string doesn=E2=80=99t = 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=E2=80=99. So if that string could be filtered before it=E2=80=99s 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=E2=80=99m not familiar enough with the pip or python packaging source = code to be able to suggest code patches, but I=E2=80=99m 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-j= ust-got-a-bit-stricter [2] https://github.com/pypa/pip/pull/11088 [3] = https://github.com/pypa/pip/commit/db062e8574ee78fc7a61ec3aff070395dec409f= f#diff-f38594dcdb284279fd0fb84ffc243fb2231337517f4b3ad572bd1ae809ecb524R7 [4] = https://packaging.python.org/en/latest/specifications/platform-compatibili= ty-tags/#platform-tag
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10FABC99-E00A-4175-9B50-362FD6FDD96F>