Lots of mypy processed launched after bulk search/replace

[PeterJCLaw]

If you have a large project that uses mypy and in that project you do a large find/replace across several files then you seem to get a mypy process launched for each file that is modified. I've observed the impacts from this being anywhere from a mild slowdown of my computer for a few moments to it causing my desktop (as well as several of the mypy processes) to OOM requiring a logout.

The OOM failures are likely to be hard to reproduce with a small project, however the launching of lots of mypy should be observable.

I'm on Ubuntu 20.04 with extension version v2022.12.0, though I've seen this on older extension versions too.

It would be great if the extension could limit the number of processes launched in the case of a bulk search/replace happening (perhaps to the number of cores?) or, better, launch a single mypy process for the whole update.

[karthiknadig]

@PeterJCLaw One of the things that we are trying to do for linting is moving it over to lint over LSP. We recently released pylint extension that uses this design. This way we run the linter in a server like mode and we avoid running a separate instance of the linter per file.

To make it easier for people to build linting extension we also created an extension template. If you have any interest you could look into creating a mypy extension based on that template. The idea with the template was to make it very easy to build and maintain linting or formatting based extensions. That template works over LSP, and can handle parallel requests, and could be adapted to use the mypy daemon as well.

[PeterJCLaw]

Ah, that makes sense. Is the plan then to end up with a suite of extensions that users should install? I have to admit I quite like that at the moment there's just a single extension for "python" which pretty much does everything you need.

I guess I'd assumed that maintenance of a single extension would be easier too, as boilerplate things like handling subprocess IO would be handled once rather than having several copies to keep up to date, though perhaps some of that goes away anyway?

[karthiknadig]

There are few reasons why we wanted to do this:

1. The need for installing your own tools. One of the problems in the extension is tool installation, if someone needs say mypy they have to install it themselves, or we provide an API for installing. The problem here was that people often installed in the wrong environment. In the case of using our APIs, when people were using things like conda or poetry, we would not update the "lock" file, or may not even update the right "lock" file.
2. Deeper integration with the tools. One of the limitations of the python extension is that if we want to expose some deep integration feature from one of the tools then you are limited to what is commonly available across all the tools. With the individual extension now you can light up specific features for each tool. For example, in the isort extension, we can detect that imports are not sorted, show that as problem, provide code actions to resolve it, and support the organize import command. Without having to special case it. Same with black, in the black extension we are able to handle unsaved file buffers, format it, the provide the formatted content for saving. In the python extension, we have to support this generically, and some formatters don't have stdin support in notebook and script scenarios, to do this on raw unsaved content.
3. Support for uncommon tools. Another issue with our extension was the limitations to integrating new or uncommon tools. Users had to wait for us to provide support since most python users were not familiar with TS or we were not comfortable taking on yet another tool for maintenance reasons. The templates were specifically designed to have most of the actual code lives in python. So, it should be easy enough to do it. For example, we had some user create ufmt extension based on the template, which we previously rejected as a feature to support in the main extension.
4. The template does not restrict to linting or formatting, you can basically build any tool that can make use of language server. Like if you like to provide type analysis, completions, pretty much anything that your tool can offer you can provide that via the template. The idea was to provide a way to extend beyond the things that the core python extension can provide.
5. Discoverability, people look for tools by searching for them in the extensions. This is one of the feed backs we got on the tools.

reference: https://twitter.com/brettsky/status/1555632119312879616

From the maintenance point of view, for the short term there is definitely lot more work, but once we have a stable set of things covered in the template and LSP implementation, we believe that the maintenance load should be considerably smaller.

[Sesota]

I'd like to bring this issue to notice again. This is quite annoying that a bunch of mypy processes run whenever I:

• find and replace
• rename a python file or a variable
• move a file

There are a lot we can do other than "having another extension for mypy". or until the eventual release a robust mypy extension you can either:

• Put a configurable limit on the number of mypy processes invoked by the extension.
• Only run mypy for the files that are already opened in the editor, not all the files in the workspace.
• Put mypy requests on a queue that only a limited number of them be run simultaneosly.

[karthiknadig]

Please try this preview extension for mypy. It ships with mypy, and uses dmypy to as the service to run linting and most of the linting code is written in python so it is easier to contribute to.

https://marketplace.visualstudio.com/items?itemName=ms-python.mypy-type-checker

[github-actions]

Because we have not heard back with the information we requested, we are closing this issue for now. If you are able to provide the info later on, then we will be happy to re-open this issue to pick up where we left off.

Happy Coding!

[PeterJCLaw]

@karthiknadig sorry I wasn't able to test this sooner. That extension does seem to solve the issue of spinning up lots of separate processes (observed via htop; I don't have an easy reproduce of the original issue to hand), however I'm finding that it also produces mypy errors which don't match running mypy on the command line (whereas the Python extension does match running on the command line).
The cause of those issues seems to be microsoft/vscode-mypy#89, which is a significant blocker to adoption of that extension.

[karthiknadig]

@PeterJCLaw Can you share the list of process? with the extension there should only be mypy.dmypy per workspace.

Just for clarification, when testing out the extension did you turn of mypy from python extension?

[PeterJCLaw]

For clarity: I was confirming that the other extension does indeed appear to be free of this issue.