MyPy Plugins not supported

[ewianda]

Description.

Using mypy plugin doesn't seem possible.

cat mypy.ini
[mypy]
ignore_missing_imports = True
plugins = pydantic.mypy

external/mypy_integration_config/mypy.ini:4: error: Error importing plugin 'pydantic.mypy': No module named 'pydantic'                            
Found 1 error in 1 file (checked 1 source file)    

Solution.

Make _mypy_cli configurable so users can customise accordingly.

[thundergolfer]

Yeah plugins aren't supported at the moment. Can I edit the title of your issue to say "MyPy Plugins not supported" and leave this open until they are?

[cristianmatache]

+1
I am a sqlalchemy-stubs user. Would also love this feature.

[thundergolfer]

Any ideas about how'd you want this supported, ideally? At the moment the plugin's dependency on mypy is kept separate from the application code's dependencies (specified in a requirements.txt somewhere).

If you wanted to use the pydantic plugin, the plugin could add the ability specify plugin packages that it should install, but then you'd be specifying pydantic as a dependency in two places. Once for the plugin and once for your application code. The versions would need to be kept in sync too.

It might be possible to have the plugin accept labels directly, so that you could pass a package you've installed for your application code directly to mypy, like:

mypy_integration_deps(
    mypy_version="//:current_mypy_version.txt",
    plugins={
       "pydantic.mypy": requirement("pydantic"),
   }
)

Just spitballing here though... 🤔

[cristianmatache]

I quite like your suggestion. 👍

[atadau]

Another +1 on this. I'm looking to add this to our code base, and we have a couple of in house plugin (the mypy config point directly to the .py file) so would be great if that can be supported as well

[thundergolfer]

we have a couple of in house plugin (the mypy config point directly to the .py file) so would be great if that can be supported as well

Oh interesting, never done that. I think plain .py path references could prove tricky in Bazel, but providing a py_library target and then referencing the import path myworkspace.path.to.internal.plugin in the config file would be an easy substitute if I could get that working.

[kwestb]

In my own build, I hacked together a solution that works for us by patching this code in the following way:

diff --git a/mypy/BUILD b/mypy/BUILD
index c8f843d..ac34fc3 100644
--- a/mypy/BUILD
+++ b/mypy/BUILD
@@ -1,4 +1,4 @@
-load("@mypy_integration_pip_deps//:requirements.bzl", "requirement")
+load("@mypy_integration_pip_deps//:requirements.bzl", "all_requirements")

 py_binary(
     name = "mypy",
@@ -6,13 +6,7 @@ py_binary(
     main = "main.py",
     python_version = "PY3",
     visibility = ["//visibility:public"],
-    deps = [
-        requirement("mypy"),
-        # Transitive deps determined by looking at: https://github.com/python/mypy/blob/master/mypy-requirements.txt
-        requirement("typing_extensions"),
-        requirement("mypy_extensions"),
-        requirement("typed_ast"),
-    ],
+    deps = all_requirements,
 )

 filegroup(

And then adding all of my plugins to //tools/typing:mypy_version.txt (in addition to the MyPy version) so that they are available at runtime.

[jonasrauber]

Any updates on this?