Entry point plugin manager

[mdickinson]

This PR adds a simple plugin manager that retrieves its plugins from entry points. This is intended to replace existing plugin managers like the EggPluginManager, EggBasketPluginManager and PackagePluginManager that are more closely tied to package details - the goal is to better separate Envisage from those packaging details and rely on setuptools, importlib.metadata and other third party packaging tools to take care of those instead.

The minimal use looks like:

plugin_manager = EntryPointPluginManager(group="fancy_application.plugins")

after which plugin_manager.start() will find all plugins on the current Python environment registered under the fancy_application.plugins entry point group, and instantiate and start them.

Alternatively, a collection of entry points can be provided directly via the entry_points trait. In this case, the value of the group trait (if any) is ignored.

Other plugin managers have various forms of filtering built in; I think we can add that later to this one if the need arises. (And the current filtering doesn't entirely work as intended, either - see #531.)

To do:

• [x] Ensure that plugins have the right application reference (if any) at all times; solve Traits initialization order issues
• [ ] Look into possible plugin dependency-order problems and solutions
• [ ] Create examples of how this could be used (ideally based on real downstream applications).

[mdickinson]

• an application which mostly hard-codes the plugins

This is the use-case I was going for. In this case I think you'd have a CompositePluginManager, where the first component plugin manager would describe the hard-coded plugins, and a following EntryPointPluginManager would allow loading of optional plugins provided by things installed into site-packages.

I'll have a go at making this work on a downstream project that's using this model.

[mdickinson]

The egg infrastructure seems to do some dependency analysis on the eggs

Yep. I'd really like to avoid that sort of complexity, if possible. For the target use-case (and even in general), it shouldn't matter what order the plugins are loaded in - a well written plugin shouldn't have start-time dependence on other plugins. (In general, a well-written plugin shouldn't have anything in its start method at all, instead creating things lazily on demand.)

[corranwebster]

There's part of me that is wondering if the right solution for Envisage generally is to simply let plugins declare dependencies via ids, validate that it forms a DAG, and then topologically sort things. Explicit is better than implicit.

[mdickinson]

let plugins declare dependencies via ids [...]

That sounds like a much more reasonable model than trying to infer dependencies from package dependencies.

[mdickinson]

@corranwebster Thanks for looking at this. I'll mark it as WIP for now and add some to-do items.

[mdickinson]

I'm going to close this; we could possibly pick it up again at some point in the future if there's sufficient motivation to do so. At present, there are relatively few downstream applications that I know of that would make use of this, and I think the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming) applies. Once we have enough examples of applications that need this, we can re-make a suitable abstraction.