Doesn't work with generated code: "k8-fastbuild is not a valid Python package name"
Opened this issue ยท 6 comments
I hit the problem because I'm using https://github.com/pubref/rules_protobuf
In general, if generated Python code is referenced, it will cause an error. In the sandbox, the files has paths like bazel-out/k8-fastbuild/bin/...
.
It's making the entire tool unusable, one option could be skipping files in bazel-out dir for now.
Looks that 2 hacks work:
(1) When build SRCS of the command line, simply ignore files with path prefix bazel-out/
. The downside is generated files won't be type checked. I'm using this hack now.
(2) replace --package-root .
with --package-root . --package-root bazel-out/k8-fastbuild/bin
. The problem is I don't know how to make it adapt to different build env (say k8-opt, or a non-Linux platform).
Any ideas?
If you think a repro is important, I can try to make one. Thanks!
I've created what I think is a repro of your problem here: https://github.com/thundergolfer/bazel-python-mypy-protobuf
I've also added you as a contributor in case you need to fix up any inaccuracies in my repro ๐
@cxcxcxcx see #11 that applies your second option. In particular see https://github.com/thundergolfer/bazel-mypy-integration/pull/11/files#diff-c7aad2fe686a5c09d5d246bd6242f633 Line 146
I'm sure we can come up with a safer hack :)
but it's working here
I have bumped across similar issue while using https://github.com/rules-proto-grpc/rules_proto_grpc
Getting the following error
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //data_praparation:test_mypy
.. is not a valid Python package name
Any update on this issue?
Is there a workaround for this? for anything that depends on protocol buffers or grpc I'm getting:
greeter_client_mypy.runfiles is not a valid Python package name
See build output.
@juanique @thepurpleowl Here is the workaround I'm currently using for this issue.
- Create the following
tools/mypy/mypy.patch
file to avoid running mypy on generated sources.
diff --git a/mypy.bzl b/mypy.bzl
index 2ab74fe..ec19e50 100644
--- a/mypy.bzl
+++ b/mypy.bzl
@@ -174,7 +174,7 @@ def _mypy_rule_impl(ctx, is_aspect = False):
]),
"{SRCS}": " ".join([
shell.quote(f.path) if is_aspect else shell.quote(f.short_path)
- for f in src_files
+ for f in src_files if not f.path.startswith("bazel-out")
]),
"{VERBOSE_OPT}": "--verbose" if DEBUG else "",
"{VERBOSE_BASH}": "set -x" if DEBUG else "",
- Apply the patch when downloading the
bazel-mypy-integration
.
http_archive(
name = "mypy_integration",
patch_args = ["-p1"],
patches = ["//tools/mypy:mypy.patch"],
sha256 = "9a6837afe5d4953bdfaeed8ff6572c9958845a932f835c2c1058b5fe67bf573f",
strip_prefix = "bazel-mypy-integration-0.2.1",
url = "https://github.com/thundergolfer/bazel-mypy-integration/archive/0.2.1.tar.gz",
)
- Update your
mypy.ini
to prevent mypy from following generated imports.
[mypy-your.api.module.*]
follow_imports = skip
While this solution is super hacky, it should unblock you until a more permanent solution is released. I've tested this on the rules_proto_grpc 4.0.1
, mypy 0.812
, and bazel-mypy-integration 0.2.1
and it seems to fix the problems that you guys have reported.