An interesting interaction with pip version and installing c Pants #general

An interesting interaction with pip version and in...

fast-nail-55400

11/08/2025, 3:09 AM

An interesting interaction with pip version and installing certain dependencies. (Posting in case anybody encounters it and wants a solution. ) Got this error when running

pants fmt ::

in a Pants-managed repository:

Copy code

ProcessExecutionFailure: Process 'Building black.pex from <resource://pants.backend.python.lint.black/black.lock>' failed with exit code 1.
stdout:

stderr:
There was 1 error downloading required artifacts:
1. platformdirs 4.4 from <https://files.pythonhosted.org/packages/40/4b/2028861e724d3bd36227adfa20d3fd24c3fc6d52032f4a93c133be5d17ce/platformdirs-4.4.0-py3-none-any.whl>
    Invalid specifier: 'CPython<3.14'

I had

[python].pip_version

pants.toml

set to

25.0

and not

latest

. Switching to a newer pip fixes the issue. Gotta "appreciate" that pip needs to be updated to recognize the existence of newer Python versions.

brief-scientist-13682

11/08/2025, 5:37 AM

@fast-nail-55400 that's almost certainly not what you think it means. That wheel does not have CPython anywhere in its metadata. Can you give me repro info? Pants version, custom Pex version - if any, and maybe could you re-run at

--pip-version 25.0

with

-ldebug --pex-verbosity 3

? I do not like to not understand things like this - almost always a bug lurking.

brief-scientist-13682

11/08/2025, 5:39 AM

To be clear,

CPython

is a Pex / Pants thing - it is not a wider PyPA world thing at all.

brief-scientist-13682

11/08/2025, 5:42 AM

Small lie. It's in there. but not as a specifier:

Copy code

:; unzip -qc platformdirs-4.4.0-py3-none-any.whl platformdirs-4.4.0.dist-info/METADATA | grep CPython
Classifier: Programming Language :: Python :: Implementation :: CPython

brief-scientist-13682

11/08/2025, 5:47 AM

The only CPython anywhere in sight, at least on main is in the lock, but in the ICs, which Pip should not be seeing: https://github.com/pantsbuild/pants/blob/a20fa8db6c35ec38e714fef1acacc00c4352d384/src/python/pants/backend/python/lint/black/black.lock#L364-L366

brief-scientist-13682

11/08/2025, 5:57 AM

Yeah, if you can provide any of that info, I'd appreciate it. I just tried reproing with what information is here already, using black.lock, various likely Pex versions, etc and no repro.

fast-nail-55400

11/08/2025, 9:04 PM

I had started with this commit https://github.com/shoalsoft/shoalsoft-pants-opentelemetry-plugin/commit/74d528ba19ed0ea838bc9d2e36a67703a30e3fa7 on my opentelemetry plugin, and made the changes in https://github.com/shoalsoft/shoalsoft-pants-opentelemetry-plugin/pull/122.

fast-nail-55400

11/08/2025, 9:05 PM

I tried reproducing the earlier changes in that PR to see if I could trigger the error, but now everything is fine.

brief-scientist-13682

11/09/2025, 3:11 AM

Ok, thanks for those details. I may not get to this for a few days, but I'll report back.

👍 1

fast-nail-55400

11/09/2025, 3:24 AM

In case it helps, this was on a macOS 26 arm laptop.

brief-scientist-13682

11/09/2025, 3:25 AM

Jesus. Yeah, hopefully that is not it! Thanks for the info though.

brief-scientist-13682

11/11/2025, 4:50 PM

Ok, this was straight-forward to repro. Thanks for that info @fast-nail-55400. The bug was definitely in Pex and the fix is definitively in v2.55.1. Based on

v0.5.0

of https://github.com/shoalsoft/shoalsoft-pants-opentelemetry-plugin and running

git apply -3 <(curl <https://github.com/shoalsoft/shoalsoft-pants-opentelemetry-plugin/commit/4b7ada879a7d85b4f3805bda619aa42cc539fa1c.patch>)

to get the 1st commit of your PR put me in the repro state. I then could mess with things by:

Copy code

:; git diff
diff --git a/pants.toml b/pants.toml
index bafd428..a3ec41d 100644
--- a/pants.toml
+++ b/pants.toml
@@ -34,12 +34,15 @@ unowned_dependency_behavior = "error"
 find_links = ["<https://wheels.pantsbuild.org/simple>"]
 
 [pex-cli]
-version = "v2.50.2"
+version = "v2.55.0"
 known_versions = [
-  "v2.50.2|macos_arm64|b787124d85ad26be62e64e0d2a4f6e5ecedb9b6c83e64dbcce835ccc63a1d392|4772270",
-  "v2.50.2|macos_x86_64|b787124d85ad26be62e64e0d2a4f6e5ecedb9b6c83e64dbcce835ccc63a1d392|4772270",
+  "v2.55.1|linux_x86_64|5ce8b38dfeed0a325a4dc122bdcb029436da99d5519ec9f4084c346d45761098|4786107",
+  "v2.55.0|linux_x86_64|2154df177c610f2006644863081d9688467a7082da2a19a4cef1ce18c9fdc64a|4783356",
   "v2.50.2|linux_x86_64|b787124d85ad26be62e64e0d2a4f6e5ecedb9b6c83e64dbcce835ccc63a1d392|4772270",
-  "v2.50.2|linux_arm64|b787124d85ad26be62e64e0d2a4f6e5ecedb9b6c83e64dbcce835ccc63a1d392|4772270",
+  "v2.50.1|linux_x86_64|a622f32040ccea3e196e5486d295f18c85ab61324a8a22b0bf8beb7e7741ab56|4773660",
+  "v2.50.0|linux_x86_64|644b1de1a3b961f38329ddb55aa56f9387295f6c1bcb96c15bd6f9c30e3ee31c|4772963",
+  "v2.49.0|linux_x86_64|e627c0c9fdaf3944a23c5bcd254ad07c86f62e414da4427ca34a099f0f6469c7|4846982",
+  "v2.42.0|linux_x86_64|6578c8505154f0a6ecccc87a96dee6ab8906ab29bf39ec0fa2302629e4565df6|4825813",
 ]
 
 [pytest]

And

pkill pantsd && rm -rf ~/.cache/pants && pants fmt :: --pex-cli-version=v2.55.0

(for example), to bisect in on the working state. I did not go backwards to find out where things went wrong beyond Pex 2.49.0 (still broken), since that's the 1st Pex to support Pip 25.2 which that PR's locks require; so I got lazy at this point. Long short, this was a Pex bug fixed in 2.55.1 or newer.

14 Views

Open in Slack

Previous Next