UX question: should `./pants check` be able to run...
# development
h
UX question: should
./pants check
be able to run directly on a
protobuf_source
target to check that it compiles to Go & Java/Scala?
Some nuances: • If a normal
go_package
depends on the generated code, it will get compiled as a precursor • We don't have
./pants check
run directly on third-party packages for Go. You have to compile by depending on it in a
go_package
. We didn't like the UX of
./pants check path/to/go.mod
resulting in compiling every single thing because most packages aren't consumed • reminder that you can use
./pants export-codegen
to check already that Protoc spits out files. Technically those files might not be compileable tho It would require some rework of FieldSets to get this working. But for now only trying to figure out what is optimal design
w
in the long run, maybe? but i don’t think it’s a blocker.
h
Definitely agreed not a blocker. Wondering if I should open a ticket to plan for this before I forget the idea
w
but i do think that codegen working with FieldSets would be a natural solution to this problem in general, not just for roots.
basically,
FieldSet.is_applicable(target, union_membership)
would check whether sources fields could be converted.
h
oh passing
UnionMembership
is an interesting idea. That's indeed very similar to how I'm doing this for Go's plugin hook
h
UX question: should ./pants check be able to run directly on a protobuf_source target to check that it compiles to Go & Java/Scala?
I think yes! But not urgent
👍 1