[bazel] Auto-generate .pyi files in py_proto_library rule#32872
[bazel] Auto-generate .pyi files in py_proto_library rule#32872gnossen merged 4 commits intogrpc:masterfrom
Conversation
|
Friendly bump! |
ferstlf
changed the title
XuanWang-Amos
added
release notes: no
grpc-checks
bot
added
per-call-memory/neutral
per-channel-memory/neutral
bloat/none
labels
|
Unfortunately, it looks like adding a dependency on Bazel Skylib introduces a thorny issue: This only happens on Bazel 6+, but we need to run these tests against all supported Bazel versions, including 6+. We don't use platform constraints ourself, but several of our dependencies do: So fixing that issue would become a big yak shaving exercise. Instead of using Bazel Skylib, could we do something more end-to-end? How are these |
|
Thanks for the reply, I can reproduce this problem. I was using Bazel 5.4.0 when creating this PR. Currently we don't consume the .pyi files with Bazel (or a type checker integrated with Bazel) but with Pylance/VS Code to get import resolution and auto-completion. There is a bit more to our setup, but in a nut-shell we add Bazel's output paths such as I haven't worked with type checkers in Bazel but I could give it a shot. But before I do: would it be an option to simply update to a newer version of Skylib? It seems like Skylib migrated their use of platform constraints in this commit. All we'd need is Skylib version 1.0.3 instead of 1.0.2 in grpc_deps(). I tentatively updated this PR with the newer skylib version - just so you can try it out (if bumping the version is in fact an option). Tested successfully with Bazel 5.4.0 and 6.1.2. |
Sure! As long as it works with all of our versions of Bazel. I just triggered CI so we can find out. |
|
AFAICT the newer Skylib version seems to have solved the issue?! |
copybara-service
bot
added
the
imported
With some delay, this is a PR for grpc#32564 (and previously grpc#31791). I looked into adding a regular `py_test` for this change [as suggested](grpc#31791 (comment)) but I am not aware of any effect that the presence of a .pyi stub file would have at runtime and where some sort of type-checking in a .py script would be affected. Stub files are only for use by type checkers & IDE's. I mean, something like this would work: ``` import helloworld_pb2 py_file = helloworld_pb2.__file__ pyi_file = py_file + 'i’ self.assertTrue(os.path.exists(pyi_file)) ``` But that seems really hacky to me. Instead I created a simple rule test for `py_proto_library` with Bazel Skylib which tests the declared outputs for an example `py_proto_library` target. Indirectly, this also tests that the declared output files are actually generated. Please let me know if this is sufficient.
4 participants
With some delay, this is a PR for #32564 (and previously #31791).
I looked into adding a regular
py_testfor this change as suggested but I am not aware of any effect that the presence of a .pyi stub file would have at runtime and where some sort of type-checking in a .py script would be affected. Stub files are only for use by type checkers & IDE's. I mean, something like this would work:But that seems really hacky to me. Instead I created a simple rule test for
py_proto_librarywith Bazel Skylib which tests the declared outputs for an examplepy_proto_librarytarget. Indirectly, this also tests that the declared output files are actually generated. Please let me know if this is sufficient.