This PR deprecates use of the include and exclude traits on the PluginManager base class, on the grounds that those traits don't currently work as intended (judging the intention from the tests), and that it's not fully clear how they were intended to work.
The main clients for these traits seem to be the EggBasketPluginManager and the PackagePluginManager, both of which are now deprecated. The EggPluginManager also makes use of this, though it duplicates and overwrites the functionality instead of inheriting it from the PluginManager base class.
Technical details:
the current include and exclude feed into private methods _is_included and _is_excluded, which in turn feed into the "protected" method _include_plugin, which is presumably intended to be available for PluginManager subclasses to use. There are no other uses of the include and exclude traits in the codebase.
In the PluginManager itself, _include_plugin is used (a) when iterating over the manager (via the __iter__ method), and (b) in the get_plugin method. However, the start method starts all plugins registered with the plugin manager, bypassing _include_plugin. I can't tell whether this was intentional, but it seems unlikely, and the tests suggest that it wasn't. I'd expect the result of iter(my_plugin_manager) to match the actual set of plugins started and stopped.
In the EggBasketPluginManager and PackagePluginManager, _include_plugin is also used to filter on entry point names (in the first case) and on plugin ids (in the second).
There may well be a use-case for filtering plugins, but I think we should design a working, self-consistent solution based on that use-case when it comes up in practice. I'd also expect that we may want to allow more general (and more pluggable) filtering than the current fnmatch-restricted solution. In the meantime, I don't think there's much value in keeping include and exclude around.
This PR deprecates use of the
includeandexcludetraits on thePluginManagerbase class, on the grounds that those traits don't currently work as intended (judging the intention from the tests), and that it's not fully clear how they were intended to work.The main clients for these traits seem to be the
EggBasketPluginManagerand thePackagePluginManager, both of which are now deprecated. TheEggPluginManageralso makes use of this, though it duplicates and overwrites the functionality instead of inheriting it from thePluginManagerbase class.Technical details:
includeandexcludefeed into private methods_is_includedand_is_excluded, which in turn feed into the "protected" method_include_plugin, which is presumably intended to be available forPluginManagersubclasses to use. There are no other uses of theincludeandexcludetraits in the codebase.PluginManageritself,_include_pluginis used (a) when iterating over the manager (via the__iter__method), and (b) in theget_pluginmethod. However, thestartmethod starts all plugins registered with the plugin manager, bypassing_include_plugin. I can't tell whether this was intentional, but it seems unlikely, and the tests suggest that it wasn't. I'd expect the result ofiter(my_plugin_manager)to match the actual set of plugins started and stopped.EggBasketPluginManagerandPackagePluginManager,_include_pluginis also used to filter on entry point names (in the first case) and on plugin ids (in the second).There may well be a use-case for filtering plugins, but I think we should design a working, self-consistent solution based on that use-case when it comes up in practice. I'd also expect that we may want to allow more general (and more pluggable) filtering than the current
fnmatch-restricted solution. In the meantime, I don't think there's much value in keepingincludeandexcludearound.xref: #531