Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add basic support for user-defined mypy plugins #3517
Configure them through
This is an almost minimal implementation and some features
Here are some thoughts about the design of this PR:
Looks really similar to what I have except it includes tests, so you win!
There are two other functional differences that I want to discuss:
Support for plugin options
Some plugins may want to expose user-configurable options. For example, with my docstring parser I want users to be able to specify which style of docstrings to expect (the default behavior of automatic discovery is a bit slower).
Here are three proposals for how to link plugin registration with per-plugin configuration options:
The correlation here is bit fragile and the per-plugin section headers may be difficult to grok for longer (i.e. absolute) paths:
[mypy] fast_parser = true plugins = /path/to/typeddict.py, /path/to/mypydoc.py [mypy.plugins-/path/to/mypydoc.py] docstring_style = 'google'
The following is visually clean, but can't as easily piggy-back on the current options-parsing code. (Note: I believe that
[mypy] fast_parser = true [mypy.plugins] typeddict = /path/to/typeddict.py mypydoc = /path/to/mypydoc.py [mypy.plugins-mypydoc] docstring_style = 'google'
The following dotted registration style is used heavily by mercurial, and this is what I decided on in my implementation. It piggy-backs existing options parsing code, so it could easily be extended to per-module options in the future, if we found a need for that:
[mypy] fast_parser = true plugins.typeddict = /path/to/typeddict.py plugins.mypydoc = /path/to/mypydoc.py [mypy.plugins-mypydoc] docstring_style = 'google'
Support for module plugins
You already mentioned this omission, but it should be fairly trivial to detect a plugin specifier that is path-like (
referenced this pull request
Jun 10, 2017
Regarding plugin options, I recall the options to pytest plugins driving me mad, because they appear to be pytest options but aren't in the pytest docs (and the usage message goes on and on and on...).
A more minimal alternative would be to just have different names for the plugin, one for each variation.
@miedzinski good point. I updated my examples above to include proper namespaces.
I tried to come up with some logic for the separators:
I'm completely open to other suggestions. Underscore could work in place of periods, but I found it less visually appealing.
referenced this pull request
Jun 12, 2017
@chadrik I agree that specifying options for plugins would be useful. They can be implemented in a separate PR -- it would also be good to first discuss the best way to provide them (outside this PR). Support for referring to plugins through a module name can also be added with another PR. I usually prefer keeping PRs small to make them easy to review and to keep discussions focused. Feel free to create issues for the new features.
@JukkaL that's fine as long as you don't do a release between this PR and the next, since the signature to the
This PR looks good to me.