Out of curiosity, why would "Building debugpy.pex" take 3 minutes? My pants.toml has

[debugpy]
interpreter_constraints = ["CPython==3.10.*"]
install_from_resolve = "python-default"

so I'm using a resolve / lockfile.

@silly-queen-7197 are you Mac arm? If so it's sdist + build for you. I just simulated this with Pip on Linux and get in that ballpark for time:

$ time debugpy.venv/bin/pip install --no-binary :all: debugpy
Collecting debugpy
Downloading debugpy-1.8.0.zip (4.8 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 4.8/4.8 MB 19.2 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... /
done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: debugpy
Building wheel for debugpy (pyproject.toml) ... done
  Created wheel for debugpy: filename=debugpy-1.8.0-cp38-cp38-linux_x86_64.whl size=3667549 sha256=17da0d2cb4cb0688f03da1a3d8aecf5f9de68a8c1d08bca18d1ce052a9711275
  Stored in directory: /home/jsirois/.cache/pip/wheels/b8/19/2f/5c99be87399098cf4e4210b32a29800c22607478dc751c63fc
Successfully built debugpy
Installing collected packages: debugpy
Successfully installed debugpy-1.8.0
real    1m30.336s
user    1m11.347s
sys     0m18.823s

This was observed on x86 linux and Pants version 2.16.0. We don't actually set

pip_version

in

[python]

. I'll look into trying that out. If I do

time debugpy.venv/bin/pip install --no-binary :all: debugpy

on linux it's about 26 seconds. I'd expect to get the wheel

debugpy-1.8.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl

though

Ok, it was just a guess. Failed. Setting the pip version to the latest Pants supports and re-running for a timing comparison would still be useful to help narrow things. 3 minutes is unexpected in your case where there are pre-built compatible wheels available.

Fun, I can't reproduce it.

pants --no-pantsd --no-local-cache run --debug-adapter ...

built

debugpy.pex

in about 17 seconds now. I was on a call with a coworker and we we're working through a bug. I wanted to show them how to use

--debug-adapter

with VS code. After running the command, I mentioned pants had to just setup a pex for the tool but it's usually pretty quick. Needless to say, it was a very long 3 minutes of watching "Building debugpy.pex". Must have been the demo gods. The number got to about 170s so it wasn't just restarting due to saving / changing files

Ok, that's more like it. A bit of FUD (for me) surrounds reporting of time spent in X being taken too seriously though as well. In the past the blame was not necessarily correctly attributed to the actual task taking time.