bazel-contrib/bazel-mypy-integration

File visibility failures in MyPy if "--build_python_zip" is active while running 'bazel test' on 'mypy_test' target

Opened this issue · 4 comments

Hi Jono,

I have reproducible repo to illustrate the issue that I am having, the mypy throws error when I am using combination of:
build --build_python_zip and mypy_test.

git clone https://github.com/kororo/proto-bazel
cd proto-bazel

➜  proto-bazel git:(master) bazel test //examples/foobar/src:foobar_mypy_test
INFO: Analyzed target //examples/foobar/src:foobar_mypy_test (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
FAIL: //examples/foobar/src:foobar_mypy_test (see /private/var/tmp/_bazel_wizz/7d4571e5262c107c98e149dc3e1a3e95/execroot/proto-bazel/bazel-out/darwin-fastbuild/testlogs/examples/foobar/src/foobar_mypy_test/test.log)
INFO: From Testing //examples/foobar/src:foobar_mypy_test:
==================== Test output for //examples/foobar/src:foobar_mypy_test:
usage: mypy [-h] [-v] [-V] [more options; see below]
            [-m MODULE] [-p PACKAGE] [-c PROGRAM_TEXT] [files ...]
mypy: error: Cannot find config file 'external/mypy_integration_config/mypy.ini'
================================================================================
Target //examples/foobar/src:foobar_mypy_test up-to-date:
  bazel-bin/examples/foobar/src/foobar_mypy_test
INFO: Elapsed time: 4.760s, Critical Path: 4.60s
INFO: 2 processes: 2 darwin-sandbox.
INFO: Build completed, 1 test FAILED, 2 total actions
//examples/foobar/src:foobar_mypy_test                                   FAILED in 4.2s
  /private/var/tmp/_bazel_wizz/7d4571e5262c107c98e149dc3e1a3e95/execroot/proto-bazel/bazel-out/darwin-fastbuild/testlogs/examples/foobar/src/foobar_mypy_test/test.log

INFO: Build completed, 1 test FAILED, 2 total actions

If I commented out the build --build_python_zip in .bazelrc, it works well. Worth to mention, mypy integration with aspect is working as expected. I suspect there is something missing in the link with the export_files.

👋 @kororobot, thanks for the report. I can reproduce this behaviour on my machine as well. There's some interaction between --build_python_zip and running bazel test on a mypy_test target.

We've already spoken in Slack about some earlier investigation, which I'll detail here for posterity:

On initial communication about the problem, I focused on why the config file was inaccessible to the mypy program that is invoked by a templated bash script.

error: Cannot find config file 'external/mypy_integration_config/mypy.ini'

I found that:

  1. The user's mypy.ini config file was correctly being copied into the @mypy_integration_config external repo
  2. That copied config file, external/mypy_integration_config/mypy.ini, was in the runfiles of the executing mypy_test target.
  3. The config file was present in the execution sandbox. I pointed at my local bazel-mypy-integration repo with local_repository and added ls external/mypy_integration_config/ inside the template. I could see the file in the output logs of the executing target.
  4. The config file's permissions were fine for reading. I could cat the contents of the file with cat external/mypy_integration_config/mypy.ini within the script, but mypy couldn't read it. Quite strange.
  5. If I did readlink external/mypy_integration_config/mypy.ini to resolve the relative path, then mypy could find the config file, but immediately failed to find one of the source files that were part of the test. 🤔

So I figured that there was a file visibility problem not just with the config file but with maybe all the runfiles needed by mypy.

Now that @kororobot has found that --build_python_zip is causing the issue, that's provides a new path of investigation, but right now I don't know why it would break mypy_test.


As expected, --build_python_zip doesn't need to be specified in .bazelrc. The following also breaks a mypy_test:

bazel test //foo:bar --build_python_zip

For now, a recommended mitigation is to not using --build_python_zip on the cmd line and instead just use it like this:

filegroup(
  name = "foo_zip",
  srcs=  ["//bar:foo"],
  output_group = "python_zip_file",
)

Thanks! As per discussion, I will close this issue with solution to remove --build_python_zip in .bazelrc.

I think we should keep it open, as there's some problem that's undiagnosed.