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 our issue right now is that adding more shards to travis burns us for actual productivity

I think John had some solution for that by creating multiple orgs

Yeah I remember that, but I also vaguely remember a "the jig is up" comment afterwards

And since the multiple orgs are not really surfaced to contributors (have to make multiple PRs I guess?) it's not a good long term solution

<@U097BRCBV>, <@U0ANNGE92> : hey: i'm planning to make the `classes_by_source` product optional in junit_run. shouldn't be too much churn... just need to determine whether there are any specs that represent source files during `def prepare`.

let me check…i am not sure how much that’s used after we move away from the current source-clone-reporting thingy

`classes_by_source` maps source files to classfiles

right, for coverage that was inverted then used to figure out what classes correlated with which source

then those sources would be symlinked in a dir that was used for reporting

possibly also used elsewhere not sure tho

looks like it is also used in `def get_coverage_patterns` ... hm =/

i don't think that's necessary though... could just look at the classpath

right, that was another thing…i removed that from cobertura by switching to cobertura’s native patterns

i was just wondering if it needed to be there at all, or could be dropped

well, if `get_coverage_patterns` is determining which classfiles were produced by a target, that's pretty easy... seems to be using a pretty roundabout method currently