Here's a design sketch for #1240.

Some thoughts, copied from there:

Plugin discovery options

• A. by file path. e.g. /path/to/myplugin.py. could also extend this with a MYPY_PLUGIN_PATH
  • pro: easier to write test cases (I discovered that placing a file on the PYTHONPATH within the tests was difficult, likely by design)
  • con: can't use pip to install plugins
• B. by dotted path: e.g. package.module
  • pro: easy for users to create pip-installable plugins
  • con: adding plugin modules and their requirements to the PYTHONPATH could interfere with type checking?
• C: setuptools entry points. e.g.:

  setup(
      entry_points={
          'mypy.userplugin': ['my_plugin = my_module.plugin:register_plugin']
      }
  )

Sub-Options

• shall we always look for an object within the module with a designated named, e.g. Plugin, or make this configurable as well? e.g. package.module.MyPlugin or /path/to/myplugin.py:MyPlugin (Note: I've already written some functionality for the latter in my hooks branch)
• do user plugins need to inherit from mypy.plugin.Plugin?

Plugin chainability options

• A. aggregate all user plugins into a single uber-plugin instance.
  • each method on this aggregate plugin would cycle through its children in order until one returns a non-None result. we could then cache the mapping from feature (e.g. 'typing.Mapping.get') to user-plugin instance to speed up future lookups.
  • this is compatible with the current design which passes a single Plugin instance around.
• B. register a plugin per feature. this allows you to replace the search with a fast dictionary lookup, as well as detect up-front when two plugins contend for the same feature.

Right now I'm using discovery option B and chainability option A, but this is just a starting point for debate.