Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[build] Option to disable pydrake docstrings #20260

Open
jwnimmer-tri opened this issue Sep 26, 2023 · 0 comments
Open

[build] Option to disable pydrake docstrings #20260

jwnimmer-tri opened this issue Sep 26, 2023 · 0 comments
Assignees
Labels
component: build system Bazel, CMake, dependencies, memory checkers, linters priority: medium type: feature request

Comments

@jwnimmer-tri
Copy link
Collaborator

Is your feature request related to a problem? Please describe.

When developing a new feature and iterating the edit-test cycle, we often want to test the Python code in the loop, too.

However, currently if we change a header file at all, the documentation_pybind.h header is regenerated and is nearly always different (because it contains line numbers for debugging), so all of the bindings need to recompile. That greatly increases the latency of the edit-test loop.

Describe the solution you'd like

The best solution for the edit-test cycle is to just turn off python docstrings entirely. In most cases, the development is not (immediately) concerned with how the docs look -- that's usually a final editorial pass. When working on functional testing, it would be great if every docstring was just "" (the empty string), and so there was no need to incorporate the mkdoc output into the unit test build process.

Describe alternatives you've considered

As a related improvement, we should split documentation_pybind.h into multiple files, for lower long-pole latencies and better Bazel caching. I'll be tracking that in a separate issue, though.

Additional context

Fixing this will require undoing the "nested struct namespace" trick we invented for pydrake, and returning back to the upstream approach of using macros.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: build system Bazel, CMake, dependencies, memory checkers, linters priority: medium type: feature request
Projects
None yet
Development

No branches or pull requests

1 participant