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’ve been working toward having one target per package (but combining packages where there are cycles, and there are lots of those cases).  Is this what’s encouraged or do people group packages together into larger targets?

for the purposes of cache hit rates, etc.

but you don't really get the payoff until your tests are more granular

I might also try to lower the `worker_count` (to 4) to see if that’s better or worse.

worth a shot. having 8 workers and only 2g of memory was probably slower

but 8 with sufficient memory should be better.

it's primarily a question of whether there is sufficient memory available

I see some targets taking 25-30 seconds with one a few source files, which seems high.  making because other threads are busy.

<@U3VNP5CH0> : `./pants server --open` will tell you more precisely how long each target took to compile.

...may take a while to load if the compile is large enough

<@U1R0P5TFY> : yes... to get the behaviour you expect (`b` not affected by `a`) you want soft_excludes enabled.

about compile speed: I just set this `unused_deps: ignore` and now compile output seems to be screaming past.  I’ll do more testing but I think this was a big difference.

that could be, yea... argh. might want to flip the default on that one.

if so it’s too bad because it was at least somewhat useful.  but I can run it on demand to analyze.

so many false positives there, unfortunately. we're now leaning more toward supporting it via compiler plugins rather than in zinc

so the slowness is in python? that’s surprising, but we have unused_deps set to ignore from day 1 for the reason stu mentioned

<https://github.com/pantsbuild/pants/pull/4440>

has anyone ever seen something like `Problem in nailgun protocol with nailgun server at 127.0.0.1:57792: TruncatedHeaderError(u"Failed to read nailgun chunk header (TruncatedRead(u'Expected 5 bytes before socket shutdown, instead received 0',)).",)`? i’ll dig into nailgun itself, but just in case

yea. that was the issue last time that was reported.

is it possible to give nailgun more memory? i don’t see anything on <http://www.pantsbuild.org/options_reference.html>

<@U3NHXA0F2> : yea: put it in `[compile.zinc] jvm_options`

follow up on compile speed - building from clean is still slow (killed after about 50 minutes), even though it seems like there are fewer pauses with `unused_deps: ignore`.  So I’ll need to keep looking on Monday.