Having spent an hour (unsuccessfully) trying to unpick a unit test for a change that (apparently) drastically changes the rule graph in JVM land… I’ve noticed that there’s a bunch of modules that don’t declare their dependency rules in the

rules()

functions. So I was wondering if there’s enough information in the rule graph to statically generate correct and complete

rules

functions for a given module. Is there? What would it take to make that work?

I’ve noticed that there’s a bunch of modules that don’t declare their dependency rules in the rules() functions.

Yeah, I think we should use this pattern more

So I was wondering if there’s enough information in the rule graph to statically generate correct and complete rules functions for a given module.

A major issue I can think of is unions. We don't know which you want activated, and it does matter—think toggling whether a backend is activatd

Yeah, unions would be tricky

I think it would? I can't see any concerns. Could be complicated with handling plugins, I suppose

(naïvely, having the param and return types from each

@rule

function would probably be enough, given each type should have the origin module embedded)

Like this?

╰─❯ ./pants javac_check --help-advanced
`pants.backend.java.goals.check.javac_check` rule
-------------------------------------------------

Check javac compilation

Undocumented.

activated by  : pants.backend.experimental.java
returns       : CheckResults
takes 2 inputs: JavacCheckRequest, ClasspathEntryRequestFactory
awaits 3 gets : Get(CoarsenedTargets, Addresses, ..)
                Get(CoursierResolveKey, CoarsenedTargets, ..)
                Get(FallibleClasspathEntry, ClasspathEntryRequest, ..)

Oooooh

from there you can dig further:

╰─❯ ./pants CoursierResolveKey --help-advanced

`pants.jvm.resolve.key.CoursierResolveKey` api type
---------------------------------------------------

CoursierResolveKey(name: 'str', path: 'str', digest: 'Digest')

activated by      : pants.backend.experimental.java, pants.jvm.resolve.key
dependencies      : builtins
                    pants.backend.experimental.go
                    pants.core
                    pants.engine.target
dependents        : pants.backend.experimental.java
                    pants.backend.experimental.scala
returned by 1 rule: pants.jvm.resolve.coursier_fetch.select_coursier_resolve_for_targets
consumed by 1 rule: pants.jvm.resolve.coursier_fetch.get_coursier_lockfile_for_resolve
used in 8 rules   : pants.backend.java.bsp.rules.bsp_java_compile_request
                    pants.backend.java.goals.check.javac_check
                    pants.backend.scala.bsp.rules.bsp_scala_compile_request
                    pants.backend.scala.bsp.rules.collect_thirdparty_modules
                    pants.backend.scala.goals.check.scalac_check
                    pants.jvm.classpath.classpath
                    pants.jvm.resolve.coursier_fetch.fetch_with_coursier
                    pants.jvm.resolve.coursier_fetch.materialize_classpath_for_tool

OK, that’s spectacular.

yea, that was one of my motivating factors for adding the above info to the help system too.. 🙂

🙂