Hiya, bit of a follow-up to this convo: <https://p...
# general
f
Hiya, bit of a follow-up to this convo: https://pantsbuild.slack.com/archives/C046T6T9U/p1751624716415909 I'm looking at the idea of possibly prebuilding wheels for Pants to avoid the (wonderfully named but probably undesired) YOLO builder. Thing is, if I want to do this, I need to know the Python package version to build a wheel for. The Python lockfile is JSON (kind of…), so I could parse it to get the answer, but that feels a bit janky. Is there a way I can find the locked version(s) from Pants in a less under-the-hood kind of way? Or is it safe to assume the lockfile JSON format is stable?
h
I think the right way to avoid the YOLO behavior is to make sure that Pex (via Pants) can find an appropriate interpreter on the search path. And/or simply runs Pex with that interpreter to avoid all confusion.
You shouldn’t have to jump through prebuilding hoops to work around what is basically a bug in Pants
f
I haven't had confirmation yet but it's possible we may need to build for a different architecture in the future (ARM…), in which case we'll definitely need to prebuild I think. So it would be useful to have an answer to this if there is one 🙂
h
Even then, you’d be better off running that build on ARM, unless you really have to cross-build, in which case, yes, you would need to prebuild
f
So there isn't a method to work out a package's lock version without just manually parsing the lockfile then?
h
I think that’s right, but ideally the prebuilding would be done by a new pants goal, so it can lean on the existing lockfile manipulation code
I need to think about this a little, but to a first approximation building the pex on each relevant platform effectively prebuilds the wheels. So that’s probably the way to go.