Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compare with rules_mypy #137

Open
alexeagle opened this issue Aug 13, 2024 · 4 comments
Open

Compare with rules_mypy #137

alexeagle opened this issue Aug 13, 2024 · 4 comments

Comments

@alexeagle
Copy link
Collaborator

This module https://registry.bazel.build/modules/rules_mypy is new and claims to resolve some of the issues in this repo.
It also has enthusiastic maintainers and not so much legacy baggage.
@adzenith I think we should compare this repo with that one to decide if it's clearly a superset of what we are doing.

@adzenith
Copy link
Collaborator

Honestly that one looks great. It fixes the mypy caching issue which is the biggest problem with this ruleset.

@adzenith
Copy link
Collaborator

Ok, I spent some time looking into it, and it's not a clear win.
First, individual jobs don't seem much faster, which surprised me. I thought with the caching they would go a lot faster. Some jobs even seemed to go slower.
But the biggest issue is that in order to share the caches, I guess, the mypy jobs depend on each other, so if you modify some dependency then you have to run mypy jobs down the dependency tree in serial rather than in parallel.

I have some local improvements that I've been meaning to get up here into this project. Let me try to find some time to do that.

@alexeagle
Copy link
Collaborator Author

Great, thanks a bunch for trying that out and reporting what you found.

@jbedard has been making changes in rules_ts to avoid that "run jobs down the dependency tree in serial" - but that's only recently possible because TypeScript introduced a way to create the equivalent of .pyi files quickly and without type-checking, so that each type-check action can have inputs it needs from the tree without waiting for those dependencies to type-check.
Perhaps the modern era of Python tooling includes some blazing fast (Rust?) tool that can produce .pyi files like that.

Without such a thing, I don't see how you could correctly type-check a library with no type information from its dependents, and would expect that serial chain.

@DavidZbarsky-at
Copy link

@alexeagle at one point I had a python tool that could spit out pyi files from the AST; it's actually not too bad because ast is built-in and you can just drop function bodies. I think there might be remnants of it in the repo I shared with you last time I seriously looked at mypy, in case you want to poke around ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants