Replacing the use of Mixins with composition

🚀 Feature

Use composition instead of inheritance and mixins.

A typical way of using this would go something like the following:

In such a world, the trainer can be instantiated like so:

trainer_instance = Trainer(dataset_reader_instance, model_instance, training_loop_manager, callback_instances_list, platform_specific_kwargs ...)

Here, everything non-essential including logging, early-stopping, etc. goes into the callbacks. Every callback while registering itself with the trainer, will tell the trainer what attributes it requires on the trainer to function. Once all the callbacks register themselves the trainer does a sanity check — warn if multiple callbacks want to access the same attribute, error out if two callbacks have asked for exclusive write access for an attribute, etc.

Additional benefit:

Now, the issue would be that the user has to instantiate these different instances in their final training script. We can automate that using a config manager like in AllenNLP and provide the user with a standard CLI train, test, predict commands. This way if a user wants to use their own dataset to train a model, they need to define a reader class for it in a separate file, modify one line in an existing config JSON or YAML file and use CLI command train new_config.yaml

Concern:

If the worry is that the user needs to learn about all the callbacks to even start training a model, then that can be addressed by providing a sample/default config file which includes the configuration for all important callbacks. So in essence, if the user wants to use the default training setup, they just need to copy the default training config file and change the model and dataset configuration.

Motivation

Code using mixins is hard to read, debug, extend and test if the mixins are not completely decoupled. Moreover, using composition coupled with an automatic way of instantiating classes will make for a very clean and fast user interface.

Pitch

Currently, the same as what is provided above in the Feature Proposal. Will update as/if things become more concrete.

Alternatives

Decouple the mixins, define their responsibilities clearly and have detailed “for developer” documentation describing these.

Additional context

Slack conversation link

[hadim]

My two cents is that the external API of PL has already proven it’s a good API and should not be modified (and I don’t even talk about the burden of breaking backward compatibility…).

As for the internal API, I always found the mixin pattern to be super confusing when reading PL code. That being said I don’t see a cleaner way to do it. @dhruvdcoder if you can come with a better and cleaner pattern than the current mixin one, feel free!

[williamFalcon]

If the worry is that the user needs to learn about all the callbacks to even start training a model, then that can be addressed by providing a sample/default config file which includes the configuration for all important callbacks. So in essence, if the user wants to use the default training setup, they just need to copy the default training config file and change the model and dataset configuration.

I strongly disagree with this… having to read docs to understand something means we were lazy with the API design and made something not intuitive… this goes against the core principle in lightning.

I’m happy to entertain rewriting the internals of lightning to make it more contributor friendly, but not the external API. I would look at all the past frameworks as lessons learned and not things done “correctly” – especially anything in the tensorflow and keras family which have (in my opinion) really poorly designed APIs