[Call-by-name week] Here is the tracking spreadsheet: https://docs.google.com/spreadsheets/d/1Kngp00C2_KE_d1hk3NpqMLIrNeVfevRFAKMPqQJZ8_E/edit?usp=sharing

There is a good chance that there are some finished backends which I forgot to mark off

Yep, I’ll take em

Bugs encountered while migrating: • The migration script failed to add an import for

implicitly

when run against the JVM protobuf codegen backends. • The migration script failed to put a

Process

inside

implicitly

for

fallible_to_exec_result_or_raise

resulting in rule graph errors (in Java codegen protobuf backend). • If the migration script is applied to a file again, some call-by-name usages are renamed unnecessarily, e.g.

get_source_root

to

get_source_root_get

• For the docs, the backends to be migrated must be activated in

pants.toml

. If there is an "easy" fix for any of these, would love a pointer to where to fix.

> We should probably move the "request" type for a call-by-name to be the > first positional argument so it does not need to be passed via

implicitly

> I'm surprised it sometimes isn't like that - seems like the most intuitive when making a function, but at the same time, it didnt really "matter" in the Get syntax

E       native_engine.IntrinsicError: Call(pants.backend.codegen.protobuf.scala.rules.materialize_jvm_plugins, MaterializedJvmPlugins) was not detected in your @rule body at rule compile time.

If one rule references another rule via call-by-name in the same file, then the referenced rule apparently must be defined first, or else this error results.

Ahhh, yes, this was the original problem with the rule_helper and stuff - one of the implict "rules" of using a

rule_helper

. I saw the rule, but didn't realize the location was below

Also, the rule visitor could do better at figuring out the type. Had to fix an error this way by adding a type annotation:

--- a/src/python/pants/backend/kotlin/compile/kotlinc_plugins.py
+++ b/src/python/pants/backend/kotlin/compile/kotlinc_plugins.py
@@ -136,7 +136,8 @@ async def resolve_kotlinc_plugins_for_target(
         plugin[KotlincPluginArtifactField].to_address_input() for plugin in candidate_plugins
     ]
     artifact_addresses = await concurrently(
-        resolve_address(**implicitly(address_input)) for address_input in address_inputs
+        resolve_address(**implicitly({address_input: AddressInput}))
+        for address_input in address_inputs
     )
     candidate_artifacts = await resolve_targets(**implicitly(Addresses(artifact_addresses)))

I'm offline until about 8:30pm EST - I took a quick look, but didn't have enough context offhand to green light it

Benjy approved it, all good.

These three don't need to be migrated, if someone wants to check those off

pants.backend.experimental.go
pants.backend.experimental.go.debug_goals
pants.backend.experimental.java.debug_goals

Are they in the pants.toml?

pants.backend.experimental.go

is. I guess thats the primary go backend though, I don't see one called

pants.backend.go

Hmmmmmm

Theres nothing really in there, just imports from

pants.backend.go.goals

and

pants.backend.experimental.go.register

Oh, sweet

Ok, enabled the backend and ran it just on that file

pants migrate-call-by-name src/python/pants/backend/go/goals/debug_goals.py

Running over the actual location of the register.py didn't work. ie

pants migrate-call-by-name src/python/pants/backend/experimental/go/debug_goals/::

Oh, yeah, the experimental register.py is just to "mark" the backend as experimental. All the real code is in the non-experimental path.

Sometimes there is code in the experimental path too

I don't know that I've ever seen that - but it was my understanding that it should "usually" just be a register.py - but good point, if someone registered rules there - it would need to be migrated there too