Skip to content

docs: fix misleading debugger support section in README#1054

Open
ctcjab wants to merge 1 commit into
aspect-build:mainfrom
chicagotrading:fix-debugger-docs
Open

docs: fix misleading debugger support section in README#1054
ctcjab wants to merge 1 commit into
aspect-build:mainfrom
chicagotrading:fix-debugger-docs

Conversation

@ctcjab
Copy link
Copy Markdown
Contributor

@ctcjab ctcjab commented May 24, 2026

Summary

The README's "Debugger Support" section shows a plain py_binary with debugpy in deps and DEBUGPY_WAIT in env, implying this works out of the box. It doesn't — py_binary's Bash launcher has no debugpy integration, so the env var is set but nothing reads it. Users need the py_debuggable_binary macro from examples/debugger/ which generates a wrapper entrypoint that actually starts the debugpy listener.

This PR updates the README to:

  • Clarify that a wrapper entrypoint is required (not just adding debugpy to deps)
  • Point to the examples/debugger/ directory for the complete working setup
  • Show the correct CLI usage from the example

Context

We hit this at CTC while setting up debugpy support in our monorepo. After following the README's instructions, DEBUGPY_WAIT=1 bazelisk run //:app started the app without any debugger — the env var was silently ignored. We traced it to the launcher template (py_binary.tmpl.sh) which has no DEBUGPY_WAIT handling, and eventually found the working implementation in examples/debugger/.

We ended up porting the py_debuggable_binary pattern into our build rules with one improvement: our version is runtime-gated — the debugpy listener only activates when DEBUGPY_WAIT=1 or DEBUGPY=1 is set, making it safe to use on targets that are also deployed as OCI images (no open debug port in production). Happy to submit a follow-up PR to upstream this improvement, potentially as part of the ruleset itself rather than just an example, if there's interest.

@aspect-workflows
Copy link
Copy Markdown

aspect-workflows Bot commented May 24, 2026

Bazel 8 (Test)

⚠️ Buildkite build #4008 failed.


Bazel 9 (Test)

⚠️ Buildkite build #4008 failed.


Bazel 8 (Test)

e2e

1 test target passed

Targets
//cases/current-py-toolchain-bazel-env-896:test [k8-fastbuild]115ms

Total test execution time was 115ms. 136 tests (99.3%) were fully cached saving 2m 22s.


Bazel 9 (Test)

e2e

All tests were cache hits

132 tests (100.0%) were fully cached saving 1m 50s.


Bazel 8 (Test)

examples/uv_pip_compile

All tests were cache hits

1 test (100.0%) was fully cached saving 444ms.


Buildifier      Gazelle

The README showed a plain py_binary with debugpy in deps and
DEBUGPY_WAIT in env, implying this works out of the box. It
doesn't — py_binary's launcher has no debugpy integration, so
the env var is ignored. Users need the py_debuggable_binary
macro from examples/debugger/ which generates a wrapper
entrypoint that actually starts the debugpy listener.

Update the README to clarify that a wrapper is required and
point to the example for the full working setup.
@ctcjab ctcjab force-pushed the fix-debugger-docs branch from 160ba4e to 41257a0 Compare May 24, 2026 15:24
@ctcjab
Copy link
Copy Markdown
Contributor Author

ctcjab commented May 24, 2026

The Buildkite failure is unrelated to this PR — all 183 tests passed, but the build failed because the macOS SDK download from swcdn.apple.com returned 403, and the web.archive.org fallback returned 429 Too Many Requests. This caused analysis failures for all targets that depend on @@llvm++osx+macos_sdk//sysroot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant