Skip to content

[docs] Define QDP Python public API surface for generated docs #1382

@viiccwen

Description

@viiccwen

What

Define a cleaner public API surface for generated QDP Python API documentation.

The current pydoc-markdown foundation enumerates selected implementation modules and applies a filter to avoid documenting imported helpers and internal symbols. This works for the initial docs pipeline, but the documented API boundary should be made explicit and stable.

Why

Generated API docs should reflect the public API that users are expected to import and rely on, rather than depending on implementation-module layout or ad hoc filtering rules.

A clearer public surface will make the docs pipeline easier to maintain and reduce accidental exposure of internal backend/helper symbols.

How

Evaluate and define the QDP Python public API boundary, for example by:

  • using package-level exports and __all__ as the primary public API signal
  • documenting which modules/classes/functions should appear in generated API docs
  • deciding whether a small docs manifest is needed for generated docs
  • updating the pydoc-markdown configuration to rely on the agreed public surface instead of broad module enumeration and filtering

Out of scope:

  • changing runtime behavior
  • broad website navigation changes
  • Rust API documentation generation

Related to #1346 and #1361.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions