Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

<@U053H6LQS> <@U054MQUPL> Agreed that `fasteners` look good

I'd rather use their process locking than attempt to write my own

<@U053HNE90>: <@U054MQUPL> my preferred path forward would be to switch all users of OwnerPidLockfile to the same implementation. For the global lock an pants lock we could get away with just calling fasteners directly if we wanted to.

Okay, that seems separable and basically unrelated to the specific concern here: how to fix the ivy lock

wouldn’t we lose the ability to tell users which process is holding the lock if we went the fasteners-only route? that’s generally helpful information.

I’m proposing we ~reimplement `OwnerPidLockfile` on top of `fasteners`

That's a nice-to-have, whereas locking correctly is a critical outstanding bug

and ditch our dependency on lockfile altogether since its deprecated

Eric seems to be in a hurry, which is why I'm proposing the fastest route to correct behavior

If someone picks up what you just proposed, I'd be happy to review+ship it

yeah, I think shipping the current as-is jump to `OwnerPidLockfile` unblocks him tho, no?

then we’d follow-up with an uplift of OPL to switch that to fasteners when time permits

I also have a patch that changes ivy to use fasteners (but it doesn't print who else is locking)

It unblocks him, but it's incorrect in a different way

only as much as the other existing file locks are incorrect

so why not 1) jump to the standard 2) fix the standard

We've already landed my RB in a cherry pick for Square. At this point I want to do something we can all stand the smell of  before Friday's release.

Why not jump to the correct, simple solution, then hoist that up into the standard?

Okay, in that case I like the idea of just fixing `OwnerPIDLockFile` to use fasteners and then using it everywhere

Ok, is someone on board to implement it? I have lot of other things going and we are on an EOQ deadline for my other projects

<@U053HNE90>: sounds like you were volunteering? alternatively, could revert the ivy patch for now.

I was not volunteering--and this lack of volunteers is why I'm suggesting that the quick, easy, and correct solution should go up first, followed up at someone's leisure by the extension of the "standard" incorrect solution

At the very least, I can't commit to doing it before Friday

Indeed, it sounds like Eric already has a patch ready with my proposed short-term solution

why not just land #3598 ? it sounds like its workable and heads in the desired direction

its at least an iterative improvement afaict - not flawless for sure