Move prepare_data_per_node to the DataHooks class

[ananthsub]

🚀 Feature

Motivation

We are auditing the Lightning components and APIs to assess opportunities for improvements:

• https://docs.google.com/document/d/1xHU7-iQSpp9KJTjI3As2EM0mfNHHr37WZYpDpwLkivA/edit#
• Review Lightning architecture & API #7740

prepare_data_per_node is an argument to the Trainer constructor. However, this ought to be a property of the DataHooks class, instead of the trainer. The decision of whether to prepare data on each node or only once globally should be determined by the actor that's actually preparing the data (e.g. the LightningModule or LightningDataModule)

This is similar to how automatic/manual optimization is a property of the LightningModule. That property also started out as a trainer argument before being migrated to the lightning module. Since this pattern keeps occurring, we should separately understand why it's so appealing to add things to the trainer constructor instead of a more specific component.

Pitch

• Add a property to the DataHooks class for this in v1.5
• Deprecate the Trainer argument for this in v1.5
• Remove the Trainer argument in v1.7

Benefits:

• Simplify the Trainer constructor (one fewer argument)
• Keep the data management in one place instead of two (at the DataHooks level)

Alternatives

Keep as is?

Additional context

---

If you enjoy Lightning, check out our other projects! ⚡

• Metrics: Machine learning metrics for distributed, scalable PyTorch applications.

• Flash: The fastest way to get a Lightning baseline! A collection of tasks for fast prototyping, baselining, finetuning and solving problems with deep learning

• Bolts: Pretrained SOTA Deep Learning models, callbacks and more for research and production with PyTorch Lightning and PyTorch

• Lightning Transformers: Flexible interface for high performance research using SOTA Transformers leveraging Pytorch Lightning, Transformers, and Hydra.

[ninginthecloud]

Hi, @ananthsub Can I work on this issue? Thank you~