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

Pants

(pants complains that a test of one of our internal scalac plugins has the jar copy of the code and the source tree's version on classpath. trying to use `provides` to prefer the source copy.)

and `JvmTarget` is what supports `provides`

hm... round-trip-dependencies doesn't imply that, afaik

it also implies that `jar_library` supports sources...

<@U0N6C2Q9F> : but you get the gist of what it is suggesting?

it uses the `provides` as way to identify code coming in via a jar or via source, in the case of our test of the plugin both are on classpath

basically, if `com.foobar.example#lib` is a transitive dep of something in 3rdparty, if you have something in your local graph with a provides clause, that local something takes precedent (at least when `ivy` is in use)

I could also just disable the plugin when compiling tests

is there a way to change pants options based on which goal is active?

what we do with ivy here is look at all `provides` clauses in the context, and add excludes for them to the remote jars

```is there a way to change pants options based on which goal is active?``` no

ah so no multiple values for `compile.zinc` -&gt; `scalac_plugins`

but if you think about it, it would require compiling things multiple times based on the requesting task (cc <@U051221NF> : it would be like `Variants`)

I imagine you'd have to bake it into artifact fingerprints and rebuild and such

but we do not currently compile a target multiple times within one run