Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/django-simple-deploy/django-simple-deploy/issues/313 below:

Implement a plugin model · Issue #313 · django-simple-deploy/django-simple-deploy · GitHub

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.

• Research pluggy.
• See datasette as an example.
• Consider using ABCs to enforce structure? See Prepping for plugins #283. Don't need, just require that specific hooks are implemented.
• General process:
  • Implement an internal plugin model.
    • Move platform-specific code to isolated subdirs. Implement an internal plugin model #325
    • Refine internal plugins; move PlatformDeployer to separate file, some cleanup. Refine internal plugin model #326
    • Uncouple tests from core. 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. See Move plugins to separate repos #361.
  • Refine to the point it can support third-party plugins with a clear integration process.
  • Announce.
• Write a brief ADR.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4