high-yak-8589912/13/2022, 9:41 PM
bitter-ability-3219012/13/2022, 9:45 PM
high-yak-8589912/13/2022, 9:56 PM
bitter-ability-3219012/13/2022, 9:59 PM
high-yak-8589912/13/2022, 10:01 PM
busy-vase-3920212/13/2022, 10:03 PM
enough-analyst-5443412/13/2022, 10:18 PM
but Pants does not support. That leaves the lock untouched except for updating the listed
pex3 lock update --lock my.lock -p project_with_security_fix -p project_with_security_bug<2.0.0+buggy_release
projects and their transitive deps as needed if possible. This is generally useful to get bug fixes or security fixes as shown. Then there is updating a lock file, but faster than happens today. That also applies to the update form above which is also slow (under the covers it does a full re-lock pinning everything not in the
set to what was in the lock already). That requires a new feature in Pex. I experimented a good while back and you get a good speedup by doing ~: 1. Create a venv from the full existing lock. 2. Run a full lock create (or update), but using a Pip that can see the venv with stuff in it. 3. Gather the delta. It's 2 that makes things faster for not exactly understood reasons. In short, Pip resolves faster that way / its algorithm shortcuts some stuff. That's the speed folks are used to with Pip since most people run Pip in a non-empty venv. Pex is currently hermetic and always runs Pip in an empty venv.
high-yak-8589912/13/2022, 10:38 PM
enough-analyst-5443412/13/2022, 10:42 PM
to get a verbose log and scrapes that for resolve data. IIRC that log is different from what Pex currently expects in a normal full resolve; so there needs to be changes to log parsing / calculations performed using it + old lock data.
pip --log ...