https://pantsbuild.org/ logo
#development
Title
# development
w

witty-crayon-22786

12/16/2021, 7:00 PM
interested in your thoughts on a potential pattern: there are a few different target types which should be treated as “root only” on the JVM (such that we should fail at compile time… or preferably earlier) if a dependee requests a classpath for them. examples: 1.
deploy_jar
, 2.
(scala_)junit_tests
3. (any other root target)
1
i’m thinking of adding a union that would declare these types such that they can legally be used as the root of a request for a classpath, but fail when used as an inner node (although that might be too strict for tests, since it’s likely that folks have test targets depending on other test targets, despite that being questionable)
h

hundreds-father-404

12/16/2021, 7:04 PM
since it’s likely that folks have test targets depending on other test targets, despite that being questionable)
Is it? This is a huge reason I felt so strongly about https://github.com/pantsbuild/pants/issues/13238 for Python land. (Although in Python, it is legal for a test to import another test)
w

witty-crayon-22786

12/16/2021, 7:04 PM
i’m wondering whether to have the union include a particular
Field
on the targets, or the
Target
type itself
h

hundreds-father-404

12/16/2021, 7:06 PM
The Target API is meant to be field-driven so that we're robust to users writing custom target types. So you could use a private "sentinel" field as a marker I started to move away from a field-driven API with target generation being based on the target itself, but I'm still not 100% convinced that was the right approach
w

witty-crayon-22786

12/16/2021, 7:07 PM
Is it?
it might be alright if the testrunner is carefully configured to only run the root tests, rather than all tests on the path. but otherwise it leads to tests running multiple times: once for each test target that depends on them. it’s also never a good idea for library/prod code to depend on tests, and “no dependees” defends against that as well
@hundreds-father-404: right now, the
resolve
field is a really obvious marker. but i do think that we’re going to want to replace it with
compatible_resolves
for consistency
1
h

hundreds-father-404

12/16/2021, 7:08 PM
Right, I agree it's not a good idea for tests to depend on tests. I'm questioning if people actually are doing that in the wild?
w

witty-crayon-22786

12/16/2021, 7:08 PM
I’m questioning if people actually are doing that in the wild?
in a random tailored repo… probably? but perhaps not.
h

hundreds-father-404

12/16/2021, 7:09 PM
To be clear, are you thinking of inferred dependencies between tests? That regardless of Pants, you have Java test code that imports another test file?
w

witty-crayon-22786

12/16/2021, 7:10 PM
@hundreds-father-404: i guess that i could just pick some other random field which is distinct for each of these targets to put in the union
👍 1
To be clear, are you thinking of inferred dependencies between tests? That regardless of Pants, you have Java test code that imports another test file?
right. especially since it is file level
not super common, but possible. easy to do in Python, easy to do in Scala… little bit harder in Java
h

hundreds-father-404

12/16/2021, 7:10 PM
Got it. I can't comment to how frequently that happens in JVM, not enough experience. But I do know it's legal and does happen in Python