[internal] refactor scrooge codegen to allow for multiple languages

[tdyas]

The Scrooge Thrift generator supports multiple languages. Refactor the Scrooge backend so it is structured in a similar manner to the Apache Thrift where each language is its own backend. This will open the way for introducing the Java and Android Scrooge backends.

[Eric-Arellano]

How will this interact with Apache Thrift for Java? Users must opt-in to whichever generators they want, so it's easy for them to choose between Apache Thrift vs. Scrooge.

But does it ever make sense to generate both? I wonder if they use the same file name scheme, such that it would cause a merge conflict with MergeDigests.

[tdyas]

How will this interact with Apache Thrift for Java? Users must opt-in to whichever generators they want, so it's easy for them to choose between Apache Thrift vs. Scrooge.

But does it ever make sense to generate both? I wonder if they use the same file name scheme, such that it would cause a merge conflict with MergeDigests.

The Scrooge Java code generator actually aims to replicate what the Apache Thrift Java generator does. Users should never activate them both at the same time.

[Eric-Arellano]

Users should never activate them both at the same time.

Cool. I wonder how we could reduce the risk users do this...Right now, you'll get a confusing engine error about MergeDigests failing.

Docs should probably mention the assumption.

Maybe we introduce the concept of mutually exclusive backends? Our generic BuildConfiguration will error with a good message if you try activating both. Wdyt?

A quick-and-dirty solution would be for each backend to use ThriftSourceTarget.class_has_field() to see if plugin fields are activated from the other backend.

(This discussion isn't blocking, but probably worth at least figuring out our direction.)

[Eric-Arellano]

I really like how you organize these backends :)

[jsirois]

Users should never activate them both at the same time.

It's worth noting that the acid test for the engine experiment in 2015 was in fact supporting both at the same time in one codebase and being able to select which was desired per target. That test was driven by real Twitter use / needs at one point in time. It would be great to be able to support this sort of tortured codebase eventually, maybe.

[Eric-Arellano]

It's worth noting that the acid test for the engine experiment in 2015 was in fact supporting both at the same time in one codebase and being able to select which was desired per target. That test was driven by real Twitter use / needs at one point in time. It would be great to be able to support this sort of tortured codebase eventually, maybe.

Good to know! It would be easy to support. Register a plugin field on thrift_source for each backend to toggle it per-target. If disabled, simply return EMPTY_DIGEST in the codegen rule. So, even though both backends would run, there'd be no merge conflict.

[tdyas]

Wrote up the discussion at #14041.

[stuhood]

Users should never activate them both at the same time.

It's worth noting that the acid test for the engine experiment in 2015 was in fact supporting both at the same time in one codebase and being able to select which was desired per target. That test was driven by real Twitter use / needs at one point in time. It would be great to be able to support this sort of tortured codebase eventually, maybe.

And that eventually evolved into "variants", which became "multiple Params in a subgraph" (see #13882 (comment)). So I do think that the path specified by labeled deps / #13882 is likely to be viable.