Will any of the future releases allow for utilizing the more incremental form of computing a lock file? I believe pex supports not recomputing from scratch each time.

Eventually. You wanna pick up the ticket? 😛

If it's an easy one, maybe I have some tinker time over vacation coming up

The update command requires additional args, so I think it'd be more along the lines of new CLI on the

lock

?

Ah right since you need to be able to specify packages you'd like to explicitly update (at least that's how pip-tools was)

Is there a ticket already written for this? If not, let's get one so that Nathanael and others have something to refer to.

There are two orthogonal things here. There is updating part of a lock which Pex supports via

pex3 lock update --lock my.lock -p project_with_security_fix -p project_with_security_bug<2.0.0+buggy_release

but Pants does not support. That leaves the lock untouched except for updating the listed

-p

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

-p

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.

🔥 Speed 🔥

Yeah, so the speed is the harder project.