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

Pants

Likewise, the `export` goal needs a whole view of the graph, to give tooling the full picture

FYI, we've hit a bug in <@U053HNE90> ivy lock patch. We're seeing a stale lock file. ~/.ivy2/pants/pants_ivy_lock.lock
This was introduced in our upgrade to pants 0.0.75.  I filed an issue: <https://github.com/pantsbuild/pants/issues/3075>


You're sure there isn't a process running?  The presence of the lock file isn't what keeps the lock

The work around is to just delete the file. I've seen this twice now in the past two weeks.

It's the system flock that holds the lock, which dies with the process

There is no process names Pants or ivy running

Happened once on Mac and once on Linux too.

The laptop dev did ./Pants clean-all and it didn't fix it, this would have killed all Pants tasks. I did a ps on the xi builder and didn't see pants

(I'm commuting now and won't be able to respond)

<@U053HNE90> and <@U053H6LQS> : are you talking about different things?  Eric's comment lists the _ivy_ lock file, and, IIUC, Patrick introduced a _pants_ lock for its ivy work at a higher level

erm, nmm, looks like the _pants_ lock is confusingly homed in the ivy dir

Yeah.  It's a pants lock on using that directory for resolution

<@U053H6LQS>: `./pants clean-all` won't kill _all_ pants processes... just for the one in the current working copy

so multiple working copies could be in play maybe.

that only kills ng processes for the current buildroot, you’d want `./pants ng-killall --everywhere`

but iirc, the lock file itself should contain the pid that locked it

assuming its using OwnerPrintingPIDLockFile

...frak. went to normalize literal file lists with globs, but literal file lists don't actually validate that their sources exist, and all of the unit tests rely on that.

so `target(name=.., sources=['Literal.java'])` will always report that 1 source, even if its not on disk

...and fingerprinting just skips it, i suppose.

see <https://rbcommons.com/s/twitter/r/3592/> ... create_sources_field used to just instantiate a list of strings, which never actually checked that those paths existed

wonder whether i should now be stuck adding validation that causes an explosion when the sources _don't_ exist.

Regarding the `pants_ivy_lock.lock` issue,  the problem with the lock file is very easy to replicate.  Just touch a file and it reproduces.  From reading <http://docs.openstack.org/developer/pylockfile/> this doesn't use flock().