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

Pants

<@U0AR49RCK>: so, the gist of this is that for the last two pants summits (one year?) we've discussed the enginer refactor, but twitter was dealing with a bit too much debt to actually dive in

there have been notes, and 4 folks have a pretty good idea of what needs to happen, but it's not all spilled out on paper

twitter's out of the hole now, so it's time

Great. For those of you playing along, I'm interested in learning more about Pants and its engine and its possibilities.

```[info] Compiling 3 Scala sources to /Users/stuhood/src/source/.pants.d/compile/jvm/zinc/isolated-classes/util.util-registry.src.main.scala.scala.jar...
[info] Compiling 15 Java sources to /Users/stuhood/src/source/.pants.d/compile/jvm/zinc/isolated-classes/util.util-core.src.main.java.java.jar...
[info] Compiling 15 Scala sources to /Users/stuhood/src/source/.pants.d/compile/jvm/zinc/isolated-classes/util.util-stats.src.main.scala.scala.jar...
[info] Compiling 5 Scala sources to /Users/stuhood/src/source/.pants.d/compile/jvm/zinc/isolated-classes/util.util-collection.src.main.scala.scala.jar...````

```ERROR] Error while writing to artifact cache: Failed to PUT <http://fs-artifactcache1/pants_backend_jvm_tasks_jvm_compile_scala_zinc_compile_ZincCompile/.pants.d.gen.spindle.scala_record.src.thrift.com.foursquare.api2.service.service-scala/87344972918b4f8113b78cda7e7128c0c01d4136-TaskIdentityFingerprintStrategy.5a59be27e3cf_f0d61ed03397.tgz>. Error: 413 Request Entity Too Large```

We seem to now be writing artifacts so large that varnish/nginx are not configured to handle them

I'm guessing this is just the combo of jar + classfiles?

Oh yes, in all things and in all ways, it's always codegen in the end

yea... 2x was enough to push you over some limit

I'm sure the limit is arbitrary, so easy enough to fix

so... does this mean you're switched over...?

<@U053HNE90>: so, in theory we could cache only the jar and extract it during post-fetch... caching both was my laziness during the period where the jar was optional

Reducing artifact sizes is a non-trivial gain

...shit. that would solve the problem <@U066LC126> spent so much time solving =(

We spend some real time on network fetch for artifacts in several of our benchmarks that are representative of real user behavior

Better to solve a problem twice than never

I have the entire isolated upgrade email cooked up and sitting in gmail right now