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

Pants

Thinking of the work <@U053H6LQS> has on cleaning up ivy isms in the dep nodel

we have lots of mid-graph excludes though =(

would be great to deprecate them at the very least.

<@U04S45AHA>: in their current form they don't exist in maven, but in the form you'd imagine that they should have, they definitely exist in maven. imagine that you're a maven project in the middle of the graph: when you apply an exclude, you don't see a dep anymore, but you don't affect projects downstream of yourself

Well, that's a pantsism resulting from a single ivy.xml used for resolve

I think ivy nested excludes work exactly like pom nested excludes

And the ivy global excludes just have no equivalent

If each pants internal lib target got its own generated ivy.xml with links to others and that was resolved,  you'd be back to apples apples

What's the proper way to pass in `-source` and `target` to zinc? Looking in `scala_compile.py`, there doesn't seem to be any mention of `-source` or `-target` to begin with. Giving them to `zinc_args` crashes, and giving them to `jvm_options` just causes it to hang until the nailgun server times out.

Oh, nevermind, found it. <https://github.com/typesafehub/zinc> is helpful.

<@U04S45AHA>:  argh... got that exactly wrong. maven excludes don't affect projects _upstream_ of themselves.

So if we emitted a graph of ivy.xml, 1 per target in the current graph, then resolved the root, the current target.excludes could be made to work just like the JarDependency excludes - and thus like mvn

Which I'm guessing is where you're headed

nick has a plan that involves fully reifying excludes so that they can be applied similarly to UnionProducts

because we can't apply mid-graph excludes via ivy as far as i know.

his idea is the inverse though. apply excludes in python

The less you rely on ivy to do the right thing, the more likely the right thing is to happen

yeah. I've found that to be a good guiding principle

Put it this way - if we used mvn aether as our resolver, we'd have the _same_ problem if we synthesized 1 (logical) pom.  If we synthesized a graph to match our target graph, things would work like an ivy mulit-module project with pom per project

I think ivy's main problem is the gpg problem, it actually does what you tell it for almost everything (1 real bug I know of).  The issue is telling it what you want is very hard

BUT there is definitely an ivy exclude bug related to intransitive