Ale: Consider supporting dmypy

[w0rp]

The latest version of mypy now ships with its own special daemon for checking for type errors faster. It might be nice if ALE supported this in some way or another, possibly including an additional plugin which uses ALE.

Implementation Notes

dmypy writes a dmypy.json file which looks like this:

{"pid": 26666, "sockname": "/where/ever/dmypy.sock"}

dmypy doesn't return accurate results yet, just approximate ones.

[alok]

Has the 0.610 release of mypy improved the accuracy enough?

[w0rp]

I'll have to look into it.

[ckarnell]

It looks like the daemon is now considered stable, as of the 0.750 release of mypy: https://mypy-lang.blogspot.com/2019/11/mypy-0.html

[ckarnell]

@w0rp If you gave basic instructions on how to contribute to get this working I might be able to help out.

[w0rp]

@ckarnell It's great that the daemon is stable now. Here is how I think we should handle this.

I think dmypy is different enough that we'd have to avoid breaking how people have configured mypy by adding a new linter file. We can duplicate the mypy.vim file, and if the error format is the same, we can use the same Handle function for both linters.

We can decide if dmypy should be run by searching for the dmypy.json file, using the functions we usually use in the codebase. That's probably the directory we should use as the working directory.

This is probably something I might end up implementing, if someone else doesn't, as it's one of those tools I'll probably end up needing for my day job.

[w0rp]

Another thing I think worth implementing is checking in the mypy linter file if both dmypy and mypy linters are enabled, with both being enabled by default, and if the dmypy.json file exists. If the file exists, we could skip running the mypy linter, with a new option to force running mypy. That way, people will be automatically upgraded to using dmypy, when it's available, without having to configure anything.

[ascandella]

I started looking into this as I recently introduced mypy to a large codebase at work (30 seconds to run mypy).

I started with the approach of two separate linters as suggested (copy mypy.vim -> dmypy.vim) but it was almost exactly the same. Then, I couldn't figure out the best way to detect which linters were enabled (I couldn't find other examples of linters checking ale#Var(a:buffer, 'linters') or similar.

In addition, in my usage dmypy run -- is basically a drop in replacement for running mypy, except that it's faster and has the potential to create a .dmypy.json file if you ask it to start when one's not running.

Given the above, I wanted to see what it would take to consolidate the linters so we didn't have nearly-identical logic in multiple places.

Here is the draft PR I put together (on my personal fork, not ready for upstream yet). It needs tests and documentation, but if others want to take it for a spin, I'm interested in hearing feedback.

https://github.com/ascandella/ale/pull/1

Particularly in my case, I'm interested in having ale run dmypy even if a daemon isn't already running (no .json status file), so I added the autostart option.

I've only made one tiny contribution to this repo so far, so I'm not sure if my draft approach seems better or worse from a maintainability standpoint, but I'm open to any and all suggestions. If you take a look at it and decide they belong in totally separate linters, I'm happy to code that up as well. I'd just like some advice on how you imagine the mypy linter checking whether dmypy is enabled.

Thanks again for all your hard work on this plugin!

[davidatbu]

I see this got stalled. Anything I can do to push it along?

[w0rp]

I like @davidatbu's draft. With a few tests and some documentation, that will close this issue.