🚨🚨🚨  TF: Remove `TFWrappedEmbeddings` (breaking: TF embedding initialization updated for encoder-decoder models)
Author: gante
Pull request: yes

# What does this PR do?

Banishes `TFWrappedEmbeddings` from our codebase, and updates all models that depended on it to use `tf.keras.layers.Embedding` instead. This corresponds to ~1/3 of the models that were using `TFSharedEmbeddings`.

All models, except for T5, had the same changes as TFBart -- the changes are pretty much copy-paste from each other, so you can review the PR rather quickly. Give T5 the appropriate attention, though.



Comments:
_The documentation is not available anymore as the PR was closed or merged._

@sgugger @Rocketknight1 plz check the question in the PR header 🙏 

> If I'm right about that (and I'm not sure I am!), would it make more sense to either pass names to the layers in __init__, and/or to override model.build() to do the weight creation in there, rather than putting it all in call()?

As far as I've read/tried, sadly it is not possible. The root issue is that the name of a layer is nested in the first layer it is called from by default. If the first call using layer `foo` happens inside a layer `bar`, a variable in `foo` will always be `bar/foo/variable:0`. We need to have the exact same names to cross-load weights, so we either override this nested name behavior (`tf.named_scope` with a scope ending in `/` is the only way AFAIK), or we add some per-model cross-loading logic to match the two names 😞 

I mean, yeah, we might be able to edit build, but we would have to set a named scope there as well to get the correct variable names.



Ugh, right. Moving to `build()` might be a little tidier, but it would require a lot of model-specific coding that isn't really worth it for something like that, so I'm fine leaving this where it is!

@Rocketknight1 The ideal solution would be to be able to have some flag to not inherit the nested name at build time, or to be able to inject the right named scope somehow.

Now that I'm looking again at how weights are initialized, it might work if I override [this line](https://github.com/keras-team/keras/blob/7f3aa8aaa55f087544b500286ae360489d5eba8e/keras/engine/base_layer.py#L474) 🤔 I will give it a go, since it would lead to much clearer code!

@Rocketknight1 no good -- upon further digging on how the names are created inside a Keras layer, the only useful tool/variables I found was [this internal function](https://github.com/keras-team/keras/blob/7f3aa8aaa55f087544b500286ae360489d5eba8e/keras/engine/base_layer.py#L3661) which **in theory** enables manual scope naming at layer definition time. The catch is that it sets a global variable, and would remove the correct nested names for the other layers (unless we decide to update `name` everywhere).

In practice, I wasn't able to get it to work, but I don't think it's worth diving into.

@gante Agreed, and thanks for taking the time to check it out!

(embedding weight initialization updated, à la #19460 )

@sgugger now with the updated embedding initialization (same as in the PR you just reviewed for TF Bart #19460).

As discussed, this fixes an incorrect behavior but is technically a breaking change. Should I add 🚨 to the PR title?