Replies: 2 comments 2 replies
-
|
There are a few mypy rulesets out there, I created and maintain https://github.com/theoremlp/rules_mypy. In terms of sources and typings:
Something I wish was stamped on external deps in PyInfo or some other provider is the canonical pypi requirement name — in rules_mypy we have a shoddy way of finding typing-extensions and mypy-extensions to exclude them because otherwise mypy will hard fail. Being able to easily grab direct and transitive sources and pyi files would certainly make rule implementation easier. It is not currently possible to put pyi files anywhere other than data in a py_* target, which additionally makes it difficult for code generators (like protobuf) to handle typings correctly. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the feedback!
Thanks. This provides some validation that the provider fields I proposed are a base line necessity. I'll clean up the PR that adds them.
Is this rooted in the non-site-packages based layout of external dependencies? In any case, yeah, attaching some sort of info like that to what comes from pypi is something we've talked about, but the details of what/how/etc are murky. (this has come up in the context of having a site-packages based layout instead of lots of directories on sys.path)
Something I've gone back and forth on in my head is how to pass pyi files to e.g.
I think I mostly prefer (1):
Which reminds me:
I looked at the readme. Interesting approach!
Thanks for reminding me of these. These might look a bit weird, but seem easy to model: just a py_library with pyi_srcs set and empty srcs. This seems like more support for a separate pyi_srcs attribute. |
Beta Was this translation helpful? Give feedback.
-
|
I like the |
Beta Was this translation helpful? Give feedback.
-
For libraries that come with pyi files, they'd be part of the same py_library the py files are in, and be automatically picked up. For libraries that distribute a separate |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
After seeing a few discussion about static analysis from several different places, I wanted to start a discussion about how the rules can better support such tools.
In particular, I'm interested in hearing from people implementing rules for e.g. mypy, other type checkers, or other tools, and what information would be useful for a
py_*rule to provide.The primary case I have in mind is type checkers. Strict dependency checking are a second case.
For a type checker, 3 pieces of information are needed:
For strict dependency checking, the same information is needed.
Right now...
The original py sources files aren't always directly available. While the sources are usually put in e.g PyInfo.transitive_sources et all, precompile settings may cause them to be omitted.
There are no fields to store pyi fields.
The
PyInfo.importsattribute has enough information to map files to what their imported module name will become, so that part is covered.So, I'm proposing adding 4 new fields to PyInfo:
Within Google, we carry a patch for direct_original_sources to support dependency checking.
Within Google, for our Pytype-based type checking rules, those rules have a different way of getting equivalent information (this is for historical reasons). Something notable here is they don't use
PyInfo.importsattribute for path mapping. Instead, a single File that tells how to map file paths to module names is used. I'm not sure what the pros/cons of this are compared to PyInfo.imports.Beta Was this translation helpful? Give feedback.
All reactions