rework plugin loading

docs/source/internal/plugin_handling.rst

@@ -11,44 +11,6 @@ new checks. It now supports:
 
 - alternative report formatters
 
-To facilitate this, |Flake8| needed a more mature way of managing plugins.
-Thus, we developed the |PluginManager| which accepts a namespace and will load
-the plugins for that namespace. A |PluginManager| creates and manages many
-|Plugin| instances.
-
-A |Plugin| lazily loads the underlying entry-point provided by setuptools.
-The entry-point will be loaded either by calling
-:meth:`~flake8.plugins.manager.Plugin.load_plugin` or accessing the ``plugin``
-attribute. We also use this abstraction to retrieve options that the plugin
-wishes to register and parse.
-
-The only public method the |PluginManager| provides is
-:meth:`~flake8.plugins.manager.PluginManager.map`. This will accept a function
-(or other callable) and call it with each plugin as the first parameter.
-
-We build atop the |PluginManager| with the |PTM|. It is expected that users of
-the |PTM| will subclass it and specify the ``namespace``, e.g.,
-
-.. code-block:: python
-
-    class ExamplePluginType(flake8.plugin.manager.PluginTypeManager):
-        namespace = 'example-plugins'
-
-This provides a few extra methods via the |PluginManager|'s ``map`` method.
-
-Finally, we create two classes of plugins:
-
-- :class:`~flake8.plugins.manager.Checkers`
-
-- :class:`~flake8.plugins.manager.ReportFormatters`
-
-These are used to interact with each of the types of plugins individually.
-
-.. note::
-
-    Our inspiration for our plugin handling comes from the author's extensive
-    experience with ``stevedore``.
-
 Default Plugins
 ---------------
 
@@ -56,40 +18,26 @@ Finally, |Flake8| has always provided its own plugin shim for Pyflakes. As
 part of that we carry our own shim in-tree and now store that in
 :mod:`flake8.plugins.pyflakes`.
 
-|Flake8| also registers plugins for pep8. Each check in pep8 requires
-different parameters and it cannot easily be shimmed together like Pyflakes
-was. As such, plugins have a concept of a "group". If you look at our
-:file:`setup.py` you will see that we register pep8 checks roughly like so:
+|Flake8| also registers plugins for pycodestyle. Each check in pycodestyle
+requires different parameters and it cannot easily be shimmed together like
+Pyflakes was. As such, plugins have a concept of a "group". If you look at our
+:file:`setup.py` you will see that we register pycodestyle checks roughly like
+so:
 
 .. code::
 
-    pep8.<check-name> = pep8:<check-name>
+    pycodestyle.<check-name> = pycodestyle:<check-name>
 
 We do this to identify that ``<check-name>>`` is part of a group. This also
 enables us to special-case how we handle reporting those checks. Instead of
-reporting each check in the ``--version`` output, we report ``pep8`` and check
-``pep8`` the module for a ``__version__`` attribute. We only report it once
-to avoid confusing users.
+reporting each check in the ``--version`` output, we only report
+``pycodestyle`` once.
 
 API Documentation
 -----------------
 
-.. autoclass:: flake8.plugins.manager.PluginManager
-    :members:
-    :special-members: __init__
+.. autofunction:: flake8.plugins.finder.find_plugins
 
-.. autoclass:: flake8.plugins.manager.Plugin
-    :members:
-    :special-members: __init__
+.. autofunction:: flake8.plugins.finder.find_local_plugin_paths
 
-.. autoclass:: flake8.plugins.manager.PluginTypeManager
-    :members:
-
-.. autoclass:: flake8.plugins.manager.Checkers
-    :members:
-
-.. autoclass:: flake8.plugins.manager.ReportFormatters
-
-.. |PluginManager| replace:: :class:`~flake8.plugins.manager.PluginManager`
-.. |Plugin| replace:: :class:`~flake8.plugins.manager.Plugin`
-.. |PTM| replace:: :class:`~flake8.plugins.manager.PluginTypeManager`
+.. autofunction:: flake8.plugins.finder.load_plugins

docs/source/internal/utils.rst

@@ -67,23 +67,6 @@ filename matches a single pattern. In our use case, however, we typically have
 a list of patterns and want to know if the filename matches any of them. This
 function abstracts that logic away with a little extra logic.
 
-.. autofunction:: flake8.utils.parameters_for
-
-|Flake8| analyzes the parameters to plugins to determine what input they are
-expecting. Plugins may expect one of the following:
-
-- ``physical_line`` to receive the line as it appears in the file
-
-- ``logical_line`` to receive the logical line (not as it appears in the file)
-
-- ``tree`` to receive the abstract syntax tree (AST) for the file
-
-We also analyze the rest of the parameters to provide more detail to the
-plugin. This function will return the parameters in a consistent way across
-versions of Python and will handle both classes and functions that are used as
-plugins. Further, if the plugin is a class, it will strip the ``self``
-argument so we can check the parameters of the plugin consistently.
-
 .. autofunction:: flake8.utils.parse_unified_diff
 
 To handle usage of :option:`flake8 --diff`, |Flake8| needs to be able

docs/source/plugin-development/plugin-parameters.rst

@@ -22,8 +22,8 @@ Indicating Desired Data
 =======================
 
 |Flake8| inspects the plugin's signature to determine what parameters it
-expects using :func:`flake8.utils.parameters_for`.
-:attr:`flake8.plugins.manager.Plugin.parameters` caches the values so that
+expects using :func:`flake8.plugins.finder._parameters_for`.
+:attr:`flake8.plugins.finder.LoadedPlugin.parameters` caches the values so that
 each plugin makes that fairly expensive call once per plugin. When processing
 a file, a plugin can ask for any of the following: