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

Pants

There’s one project were I had to painstakingly arrange the ordering of dependencies to make sure the right version of classes end up on the path for the right targets

That project works simply in maven just by using a single `&lt;scope&gt;provided&lt;/scope&gt;`

And I was able to get it working similarly simply in pants when I was testing things with the patch I have up for review

although i don't know how you'd get two versions of the binary dep? they're in different jars i guess?

Project `A` depends on a fatjar with lots of hadoop things in version `X`. Project `A` also depends on project `B`, which depends on different (not-fat) hadoop things in version `Y`.

Project `A` gets its fatjar through a transitive dependency, so it marks its dependency on project `B` as `provided` so that it won’t get shadowed on the classpath (since project `B` would get pulled in forced because alphabetizing)

So the status quo for that project in our repo is that it has the fatjar at the top of the dependency list of each thing that needs it, with a comment explaining the precariousness of the classpath ordering

solving those midgraph is pretty fragile though... for cases like that, we generally re-package things in 3rdparty

... got it.  Just me not knowing centos very well yet.  Installing openjdk-1.8.0 doesn't actually install the jdk stuff.. you want openjdk-1.8.0-devel lol.

i mean, graph intransitivity features would be good, for sure.

Do you guys know of anyone attemping to or already using pants to help build c or c++ projects?

<@U053HHEDG>: to solve that case, i think you need _only_ the transitivity bit.

Well it also needs the `compile` vs `runtime` bit because hadoop

right... but that is probably orthogonal, at least based on this discussion

Technically yeah, but I think it’s easier to keep track of marking one thing as `provided` than marking it as `intransitive` and also playing with `deploy_excludes` etc

in the provided case, you must reinclude it at test time, but not binary time, no?

so you've moved the location where you have to play with things

But it’s easier to include a single extra target spec in a test than it is to list out all the packages to throw away in `deploy_excludes`

for jar_libraries that define multiple `jars`

or have fatjars with all kinds of exciting things in them

It would be if `deploy_excludes` accepted a spec rather than a list of jar coordinates