<@U051221NF>: regarding <https://github.com/pantsb...
# development
w
@happy-kitchen-89482: regarding https://github.com/pantsbuild/pants/issues/14995
the most relevant bit afaict, is probably what Asher mentioned: the switch from
use_all_constraints
(old style locking) to
enable_resolves
(new style locking)
my guess is that there was a special case such that even if
use_all_constraints
, PEXes built for a different platform did their own independent resolve, rather than using the repository PEX.
Eric might know more, since they’ve* looked at the constraints added by the platforms argument
h
https://github.com/pantsbuild/pants/pull/12807 feels relevant, along with what it links to
👍 1
w
mm, and this comment which i just came across:
Copy code
request = constraints_request.repository_pex_request
    # NB: it isn't safe to resolve against the whole constraints file if
    # platforms are in use. See <https://github.com/pantsbuild/pants/issues/12222>.
    if not python_setup.resolve_all_constraints or request.platforms or request.complete_platforms:
        return OptionalPexRequest(None)
💯 1
…is probably what was doing this before.
(i’m in here for something which will only be picked to 2.11.x, so #14995 is still independent)
h
Interesting. I think that was an optimization because it's much more likely the subset of the lock file will be compatible. it's not theoretically impossible for the entire lock to be compatible, only far less likely
Benjy, this will likely be much easier to solve if you target 2.10 directly. There's a lot more complication now with the sub setting change for pex lock files. We will need to add to 2.11 as well, but start with the simpler thing to understand the solution
w
@happy-kitchen-89482: should i grab this one?
h
I don't think I can realistically do it
w
no worries. thanks.
h
but I would like to understand the underlying issue
See my comment
It seems like either there are 2 things going on, or I am misunderstanding things
w
hm… i missed it… which comment?
oh, got it.
h
For posterity: am I understanding correctly that there are two issues here: 1) performance - we used to build lambdas without building the entire lockfile, and now we build the entire lockfile, and 2) when building the entire lockfile we've actually found a case that cannot be built due to requiring the python_full_version? If so then 2) is what we should really be fixing?
w
i think that we wanted to restore the previous behavior, which was triggered by: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1649192579706629?thread_ts=1649186708.250549&amp;cid=C0D7TNJHL for
resolve_all_constraints
, but which is not triggered for
enable_resolves