Skip to content

Deprecate the BasePlugin #8988

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ananthsub opened this issue Aug 19, 2021 · 2 comments · Fixed by #9066
Closed

Deprecate the BasePlugin #8988

ananthsub opened this issue Aug 19, 2021 · 2 comments · Fixed by #9066
Labels
deprecation Includes a deprecation design Includes a design discussion feature Is an improvement or enhancement help wanted Open to be worked on refactor
Milestone

Comments

@ananthsub
Copy link
Contributor

ananthsub commented Aug 19, 2021

🚀 Feature

Deprecate the BasePlugin interface
https://github.com/PyTorchLightning/pytorch-lightning/blob/master/pytorch_lightning/plugins/base_plugin.py

cc @four4fish

Motivation

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

The BasePlugin initially started out as a unifying interface for the training type and precision plugins in lightning. however, both the training type and precision plugins have since evolved to be much broader in scope. almost all the new functionality has been added directly to these classes. it no longer makes sense to have a joint interface across these two classes, especially as we seek to evolve these independently.

Rather, the trend we're seeing is to have much narrower interfaces for specific functionality. Examples here are:

  • Cluster Environments (don't follow the plugins base class)
  • Checkpoint IO Plugin (don't follow the plugins base class)

Upcoming:

Longer term, a promising direction is that the training type plugin (or whatever its evolution is) acts as a composition of components implementing these interfaces

Pitch

  • Remove all subclass dependencies of the base plugin
  • Deprecate the base plugin in v1.5
  • Remove this method in v1.7

@awaelchli @tchaton @SeanNaren @justusschock as the plugin API is still in beta, does the 2 minor version cadence for deprecations still apply?

Alternatives

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.

@ananthsub ananthsub added feature Is an improvement or enhancement help wanted Open to be worked on refactor design Includes a design discussion deprecation Includes a deprecation labels Aug 19, 2021
@justusschock
Copy link
Member

@ananthsub I think we can do it as you proposed in your pitch. The idea was more to have an unified interface for those, but maybe we should allow them to differ.

Re the deprecation progress: I think the approach you mentioned in your pitch makes sense, since this is still in beta (likely not much longer though) but on the other hand it is one of the framework's core components so even the beta parts should be stable :)

@awaelchli awaelchli added this to the v1.5 milestone Aug 19, 2021
@awaelchli
Copy link
Contributor

Sounds good! I forgot this even exists 😅

@four4fish four4fish mentioned this issue Aug 23, 2021
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecation Includes a deprecation design Includes a design discussion feature Is an improvement or enhancement help wanted Open to be worked on refactor
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants