raaaandom thought. but: a way to get partial-but-b...
# development
w
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
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
that is definitely excellent.
this comment was more to do with the fact that we currently disable pex's cache in v2
👍 1
a
if everything is an ipex and uses the faster resolve method, we don’t have to worry about that at all
w
about not having a cache of the fetched requirements?
that would still mean you fetched everything every time for tests
a
the ipex resolve would use the normal pex cache
w
which is disabled, heh.
a
it decouples this concern from pants
...not in the ipex. when an ipex runs, it uses normal pex settings. that was my point
w
i think we might be talking about different usecases... i'm talking about for tests, mostly.
a
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)