Would it make sense to elide

RequirementsPexRequest

references to just use

PexFromTargetsRequest

(and move it's functionality into the rule that resolves the latter). It's strictly a subset (and ends up creating a

PexFromTargetsRequest

with the defaults) and I'm working on a PR which would benefit from this simplification

as in, replace

RequirementsPexRequest

with a factory function on

PexFromTargetsRequest

? yea, maybe. although doing that as a separate PR might be good, since i think we’ll want to cherrypick 14944 on its own

The logic is really hard to follow without this cleanup. At least IMO 😵

it definitely is. that sounds like a good idea.

Maybe it's because I just roll my 7 nuerons around in my skull until I get lucky but this PR took me a lot of time to map out. I think because there's 3 main cases, and each main cases has at least 2 subcases it gets really hairy. I hope https://github.com/pantsbuild/pants/pull/14238 will make the pex code much easier to grok

yeah it's super confusing to follow everything, so many abstractions

yep. PEX and multiple lockfiles both being stable is going to kick off a very lovely deprecation and removal period i think.

+1 to dedicated PR

Would y'all raze me at the stake if it's not a separate one? 👉 👈

Would y’all raze me at the stake if it’s not a separate one? 👉 👈

i’m fine with that. i guess you already touch all the same files