Thank you for `generate lockfiles

Question

< curved television 6568> Thank you for `generate lockfiles diff` I added the option in pants toml This is so nice

high-yak-85899 · Answer

woah Which release is this available in

proud-dentist-22844 · Answer

2 16 0a0

happy-kitchen-89482 · Answer

It s super great

happy-kitchen-89482 · Answer

I think we should turn it on by default

proud-dentist-22844 · Answer

I agree though it does seem to make lockfile generation take significantly longer but totally worth it

proud-dentist-22844 · Answer

It takes ~4 min to lock in the st2 repo Adding diff adds another minute or two or at least it normally goes to around 260 seconds and I saw it go over 320 or so when generating the diff

enough-analyst-54434 · Answer

Hrm That s too bad The `pex3 lock update ` which Pants does not use has supported printing this less prettily since day 1 It adds ~no extra overhead

proud-dentist-22844 · Answer

We really need to iron down the UX for dependecy management in pants beyond just `generate lockfiles`

curved-television-6568 · Answer

Nice But I m surprised it adds so much overhead did you try locking the same requirements both with and without diff

proud-dentist-22844 · Answer

I can investigate further

curved-television-6568 · Answer

< enough analyst 54434> would ve been nice if pants made better use of the pex features Another benefit of this approach though will be that it is agnostic to the lock tool being used so we can get the same information also for go and java etc

proud-dentist-22844 · Answer

Yeah I way over estimated with diff ` pants generate lockfiles resolve=st2 1 78s user 0 11s system 0 cpu 3 44 55 total` without ` pants generate lockfiles resolve=st2 1 41s user 0 09s system 0 cpu 3 16 25 total` Just goes to show that I really have no concept of time and I blink at the wrong times

proud-dentist-22844 · Answer

And that s only one run so shrug

curved-television-6568 · Answer

thanks for checking I ll keep an eye on this too anyhow

happy-kitchen-89482 · Answer

Should this be re implemented via pex we want `lock update` anyway for incremental lockfile generation officially now the community s highest priority feature request

curved-television-6568 · Answer

if done in pex we need to redo this for go js java etc too but we may have some way to communicate the diff data if there turns out to be a perf issue

curved-television-6568 · Answer

where as now what is missing is only the diff information that is missing for those other eco systems

curved-television-6568 · Answer

gt we want `lock update` anyway for incremental lockfile generation this should not affect the diff logic at all

happy-kitchen-89482 · Answer

Oh right multiple languages never mind then

happy-kitchen-89482 · Answer

but yeah possibly to communicate the diff data

happy-kitchen-89482 · Answer

or we should profile that code to see if we can speed it up seems like it should be possible

happy-kitchen-89482 · Answer

I can t offhand think why this would be computationally intensive and it s not doing any network requests

curved-television-6568 · Answer

exactly I would expect it to be rather performant as it merely parses the lockfile json and traverses it basically There are a bunch of set operations over it but still would expect it to be reasonable

proud-dentist-22844 · Answer

This lockfile is 259K in size most of my other lockfiles are in the 10s of K in size

happy-kitchen-89482 · Answer

So there s probably some accidentally egregious algorithm in there that could be discovered via profiling