Doesn't work with generated code: "k8-fastbuild is not a valid Python package name"

[cxcxcxcx]

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.

[cxcxcxcx]

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!

[thundergolfer]

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 🙂

[dmadisetti]

@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

[thepurpleowl]

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?

[juanique]

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.

[ashwin153]

@juanique @thepurpleowl Here is the workaround I'm currently using for this issue.

1. 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 "",

2. 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",
)

3. 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.