https://pantsbuild.org/ logo
#development
Title
# development
w

witty-crayon-22786

03/16/2020, 11:26 PM
raaaandom thought. but: a way to get partial-but-bulletproof caching for pex requirements in v2 would be to execute a resolve per library, rather than only for binaries.
and to feed the caches from output snapshots into the next resolve.
having said that
...we should probably just re-enable the pex cache, and trust it to be concurrency safe.
👍 1
a

aloof-angle-91616

03/16/2020, 11:28 PM
pex resolve is about to get a lot faster vis improvements in upstream pip. this is how i have been approaching the resolve time problem for ipex
w

witty-crayon-22786

03/16/2020, 11:29 PM
that is definitely excellent.
this comment was more to do with the fact that we currently disable pex's cache in v2
👍 1
a

aloof-angle-91616

03/16/2020, 11:30 PM
if everything is an ipex and uses the faster resolve method, we don’t have to worry about that at all
w

witty-crayon-22786

03/16/2020, 11:31 PM
about not having a cache of the fetched requirements?
that would still mean you fetched everything every time for tests
a

aloof-angle-91616

03/16/2020, 11:32 PM
the ipex resolve would use the normal pex cache
w

witty-crayon-22786

03/16/2020, 11:32 PM
which is disabled, heh.
a

aloof-angle-91616

03/16/2020, 11:32 PM
it decouples this concern from pants
...not in the ipex. when an ipex runs, it uses normal pex settings. that was my point
w

witty-crayon-22786

03/16/2020, 11:32 PM
i think we might be talking about different usecases... i'm talking about for tests, mostly.
a

aloof-angle-91616

03/16/2020, 11:33 PM
i think we should be using this approach everywhere. i haven’t written this up specifically anywhere else yet, though
(that’s part of my plan this week though. can resume this in a doc)