Propose and implement v1 plugin interface

[kdmccormick]

Context

Original issue: As a plugin developer, I am curious if there will be a 'v1' plugin interface

Tutor plugins are install-able via the tutor.plugin.v0 interface. The v0 implies that this interface is unstable.

Are there forseeable backwards-incompatible changes to the plugin interface? What would it take to get to v1?

Acceptance

Following his plan below, Regis propose a TEP for a v1 plugin API.

[regisb]

The answer is somewhat related to this other issue: #33
The v0 Tutor plugin interface was designed as an ad-hoc solution, and I added features pretty much as I went. There was not a lot of preparation involved. But I was aware that the plugin API was clunky, and in some cases quite simplistic, so I chose to name the API v0 to make that explicit, with the hope that we would some day improve and stabilize it.

Now that we have some experience with the current API, we can better identify and resolve its quirks and limitations, just like you did in issue #33. I'm looking forward to a v1 :)

[kdmccormick]

Great to know! Perhaps we could make Plugin API v1 milestone and start filing those limitations & goals under it.

[regisb]

Yes, absolutely.

[regisb]

Looking at the Tutor backlog in this project, it seems to me that the evolution of the plugin API is at the core of the matter. Many other items depend on this one, such as:

• The refactoring of the tutor codebase into separate plugins (#10)
• Better documentation of the plugin creation process (#29, Document anatomy of a plugin #33)
• Extended functionalities (As a developer I want better theming support in Tutor #11, Stop 'local' containers when starting 'dev' containers and vice versa #27)

Thus, I suggest to start working in priority on refactoring the plugin API. Here's what I have in mind:

• Implement the tried-and-tested actions & filters plugin pattern, which is in use both in Wordpress and in Open edX (OEP-50). Based on my initial investigations, all plugin functionalities in Tutor can be expressed in terms either of action/event or filter.
• The initial implementation of "tutor.plugin.v1" will actually be "tutor.plugin.v1alpha" to signal (pun intended) that it is an experimental API currently in development. Breaking changes should be expected.
• Development will happen in the master branch, to avoid creating a huge gap with the nightly branch.
• The "v0" API will remain available to preserve backward compatibility. But under the hood, the "v0" API from tutor/plugins.py will actually make use of the "v1alpha" API.
• As soon as I have a first PR ready for review, I will write a Tutor enhancement proposal (TEP) to discuss the implementation with @kdmccormick and the Tutor maintainers. I expect that the general idea will be non-controversial, but that there will be some discussion about the actual API.
• Once we agree on the actual implementation, all v0 features are migrated to v1alpha, we can publish and document v1. The v0 deprecation timeline should be discussed with the community, but I expect that it will not be completed before Nutmeg (June 2022).

What do you think @kdmccormick?

[kdmccormick]

Looking at the Tutor backlog in this project, it seems to me that the evolution of the plugin API is at the core of the matter.... Thus, I suggest to start working in priority on refactoring the plugin API.

Agreed entirely 👍🏻 I'd been moving towards the same conclusion.

What do you think @kdmccormick?

Your plan sounds great to me!

[kdmccormick]

This will be resolved by overhangio/tutor#599