It looks like

scala_junit_test

is using

compatible_resolves

instead of

resolve

. Is that intentional?

… no. should be a root. thanks!

Thanks! Mentioned in https://github.com/pantsbuild/pants/pull/13869, but other thing I noticed is roots aren't overriding like envisioned in your design doc

If not supplied, the default resolve will be used. Otherwise, one resolve that is compatible with all dependency targets will be used.

Will fix these both as prework to https://github.com/pantsbuild/pants/issues/13621. (Helps me to understand these code paths better also)

actually… i have more changes coming here. probably better if i do

Hm how soon are these coming? We'll be crossing paths a bit then Would it make sense for me to work on Python for rest of the day - there's some stuff I can definitely do related to #13261

@hundreds-father-404: my changes primarily touch the scala backend’s target types

if i do

What does "do" mean here specifically? I'm talking about two prework PRs: 1) fix all test targets to use

resolve

instead of

compatible_resolves

, 2) have

resolve

force the resolve rather than just mix it in. get rid of the

--use-resolve

option

i was just going to fix the one target that you pointed out.

fyi @witty-crayon-22786 I discovered two bugs with Go in Pants 2.9 while wiring up example-golang. I'm planning to work on them first today

@hundreds-father-404: if they’re cherrypickable, it would be good to wait until the visibility change is in

Doing the embed bug fix because it blocks

./pants test

working entirely, but punting on fixing

go vet

. We don't need to land

go vet

in 2.9

sounds good

I have a WIP to fix

resolve

vs

compatible_resolves

handling, and probably doesn't make sense to hand off that But the followup task I had was to add

compatible_resolves

to

jvm_artifact

target. That might be able to be split out beforehand? I've been wondering for example if we want a different

help

message for that field than the

compatible_resolves

that we use with

java_source

et al? A different

--default-compatible-resolves

option too perhaps? Even if none of it gets wired up, implementing the

help

message and thinking that through could help

sure, is there an issue?

let me push my wip

yes because internal tests are in the same package as the regular source files and are built together