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

Pants

i think it passes `-C` prefixed arguments through directly

That’s how I found it to work when I was implementing -source and -target.

nowarnprefixes implemented here: <https://github.com/pantsbuild/pants/blob/master/src/java/org/pantsbuild/tools/compiler/Compiler.java#L54>

(merging our scala zinc and java zinc configs and thinking about things)

<@U071M9KNE>: yea, <@U07A3D6AV> and <@U04S45AHA> would be interested in a remote retry patch. but i think sirois is refactoring it

<@U06A03HV1>: already in review BTW <https://rbcommons.com/s/twitter/r/2652/>

with @memoized_property, is there any way to define a setter for the property?

hi, peiyu from twitter, like to  get some feedback a project undergoing regarding to pants hitting buildcache

so we recently launched monobuild, as part of that, buildcache is used a lot more (compared to artifactory)

internally buildcache the current set up is behind a load balancer and we now hit the bandwidth limit from time to time

so to get away from this centralized load balancing scheme, two options: in process and out of process

in process, pants does SD and does a simple (probably random) LB pick a host/port

part of the argument is complicated LB isn't needed

out of process, there are many choices, finagle is the obvious one for twitter for example

need some help here to figure the proper interface for pants, so it could benefit the community

<@U053H6LQS>: do you have an example usage of `-log-filter` somewhere?

From the git changelog:
```    +[compile.zinc-java]
    +enabled: True
    +
    +args: [
    +    '-fork-java',
    +    '-log-filter', '.*X500.*',
    +    '-java-only', '-C-encoding', '-CUTF-8',
    +  ]
    ```

oooh. it's only going to be the message huh.

i think that means it's going to filter errors as well as warnings.

<@U098ZNTCN>: i'm sure we can answer some questions

<@U053H6LQS>: so, i think there is a better place to do this filtering, but it will require a bit of refactoring

would that be a problem for you guys? sounds like you're not using it yet

No we aren’t using it yet.  I did think of doing the filtering on the pants side, but that seemed very icky.

figuring out how to get this into the reporting classes and targeting the right output seemed hard, but maybe its another parameter we can pass in the LogConfig structure now that we have that in place.