Implement a plugin model

[ehmatthes]

This project can only reach its full potential through the implementation of a plugin model. That said, the fact that this involves configuration for deployment means there are security implications. A pretty careful approach to facilitating a plugin model is warranted.

There are other, simpler 1.0 tasks to close out. But closing those out after implementing the plugin model will help make sure that new architecture is done appropriately.

After implementing the internal plugin model, we should do as much refactoring as possible before splitting out into external plugins. Right now, any change that affects both a plugin and core is contained in a single release. After separating into external plugins, that would require at least two releases, and four releases if it affects core and all plugins. The benefit will be that individual plugins can be developed and released on their own schedule from that point forward.

• [x] Research pluggy.
• [x] See datasette as an example.
• [x] Consider using ABCs to enforce structure? See #283. Don't need, just require that specific hooks are implemented.
• [ ] General process:
  • [x] Implement an internal plugin model.
    • [x] Move platform-specific code to isolated subdirs. #325
    • [x] Refine internal plugins; move PlatformDeployer to separate file, some cleanup. #326
    • [x] Uncouple tests from core. #330
  • [ ] Complete as much internal refactoring as is clearly needed. Once plugins are separated, any changes that affect plugin and core will require at least two releases; four releases if it affects all platforms.
  • [ ] Move this project to an org.
  • [ ] Implement an external plugin model, where plugins are pulled out into separate repos. Unit tests should work in the standalone repo, integration tests and e2e tests should only run when core is available.
  • [ ] Refine to the point it can support third-party plugins with a clear integration process.
  • [ ] Announce.
• [ ] Write a brief ADR.

[ehmatthes]

Working notes

• [ ] See unfinished tasks in #319.
• [x] For external plugin model, see notes in #325.

[ehmatthes]

External plugin notes

• [ ] Naming/ usage issues:
  • [ ] Probably change name of --platform flag to --plugin flag? How does the availability of more than one plugin per platform affect the user interface, and documentation?
  • [ ] How does naming work if there's an open ecosystem for deployment plugins? For example, someone offers a different approach to deploying to fly? I think people need to choose names different than what's included in core, and then it's on the user to not install two plugins with the same name? Maybe if we find more than one, we ask the user which one to use?
  • [ ] What will it look like when existing plugins are moved to a separate repository? Probably figure this out first.
  • [ ] For example, if a plugin does not support automate_all, may suggest looking for a different plugin for that platform that does support automate_all?
• [ ] Is it possible to name plugins dsd-flyio, rather than django-simple-deploy-flyio?
• [ ] Update logic around validating platform name, and message if not supported. Maybe you forgot to install a plugin?
• [ ] External plugins will need to be able to modify the output of --help.