https://pantsbuild.org/ logo
Join Slack
Powered by
interested in your thoughts on a potential pattern...
# development
w
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
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
i’m wondering whether to have the union include a particular 
Field
on the targets, or the 
Target
type itself
h
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
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
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
I’m questioning if people actually are doing that in the wild?
in a random tailored repo… probably? but perhaps not.
h
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
@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
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
Open in Slack
PreviousNext
Powered by