bazelbuild/bazel · error · AssertionError

Bazel does not support execution of Python interpreters via

Error message

Bazel does not support execution of Python interpreters via labels yet

What it means

Raised in the generated Python launcher (python_bootstrap_template.txt) by FindBinary when the configured python binary path starts with '//' — i.e. someone specified the interpreter as a Bazel label. The bootstrap runs before Bazel can resolve labels to files, so label-based interpreter execution is explicitly unsupported (Case 1) and fails fast.

Source

Thrown at tools/python/python_bootstrap_template.txt:114

def FindCoverageEntryPoint(module_space):
  cov_tool = '%coverage_tool%'
  if cov_tool:
    PrintVerboseCoverage('Using toolchain coverage_tool %r' % cov_tool)
  else:
    cov_tool = os.environ.get('PYTHON_COVERAGE')
    if cov_tool:
      PrintVerboseCoverage('PYTHON_COVERAGE: %r' % cov_tool)
  if cov_tool:
    return FindBinary(module_space, cov_tool)
  return None

def FindBinary(module_space, bin_name):
  """Finds the real binary if it's not a normal absolute path."""
  if not bin_name:
    return None
  if bin_name.startswith("//"):
    # Case 1: Path is a label. Not supported yet.
    raise AssertionError(
        "Bazel does not support execution of Python interpreters via labels yet"
    )
  elif os.path.isabs(bin_name):
    # Case 2: Absolute path.
    return bin_name
  # Use normpath() to convert slashes to os.sep on Windows.
  elif os.sep in os.path.normpath(bin_name):
    # Case 3: Path is relative to the repo root.
    return os.path.join(module_space, bin_name)
  else:
    # Case 4: Path has to be looked up in the search path.
    return SearchPath(bin_name)

def CreatePythonPathEntries(python_imports, module_space):
  parts = python_imports.split(':')
  return [module_space] + ['%s/%s' % (module_space, path) for path in parts]

def FindModuleSpace(main_rel_path):

View on GitHub (pinned to e6e199d060)

Solutions

1. Use an absolute path (/usr/bin/python3) or a bare command name (python3) resolvable via SearchPath for the interpreter.
2. Resolve the label to a file yourself (e.g. via a genrule/$(location) expansion) and pass the resulting path, never the raw '//' string.
3. Upgrade to a bazel version / rules_python setup that fully supports label interpreters for your rule set instead of the legacy bootstrap path.

Example fix

# before
python_interpreter = "//tools/python:python3_binary"

# after
python_interpreter = "python3"  # or an absolute path like "/usr/bin/python3"

def valid_interpreter_spec(v):
    return bool(v) and not v.startswith('//')

When it happens

Trigger: Setting --python_top/--python interpreter configuration (or a rule attribute like python_interpreter) to a value like '//tools/python:py3' in a context that flows into PYTHON_BINARY for the stub script.

Common situations: Migrating from --python_path to label-based interpreter config too early; rules passing $(location //...) style values into the interpreter field; toolchains expecting label resolution where the template only accepts paths.

Related errors

• Cannot find .runfiles directory for %s
• Could not find python binary: {PYTHON_BINARY}
• Python coverage tool %r not found. Try running with VERBOSE_
• Runfiles failed to resolve {path}
• Runfiles resolved {path} to {binary} but the file does not e

AI-assisted analysis of bazelbuild/bazel@e6e199d060 (2026-08-14). Data as JSON: /api/errors/bbb6f117c0a14417. Report an issue: GitHub.