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

Provider init callback needs to be documented #182

Closed
tetromino opened this issue Aug 16, 2023 · 0 comments · Fixed by #224
Closed

Provider init callback needs to be documented #182

tetromino opened this issue Aug 16, 2023 · 0 comments · Fixed by #224

Comments

@tetromino
Copy link
Collaborator

tetromino commented Aug 16, 2023

If a provider has init specified, we want to document it.

In other words,

def _my_info_init(a, c = "hello"):
    """
    MyInfo constructor

    Args:
          a: Value of field a
          c: Value to frobnicate
    """
    return {"a": a, "b": frobnicate(c)}

MyInfo = provider(
    doc = """This is my provider""",
    fields = {
        "a": "Field a",
        "b": "Field b (frobnicated)",
    },
    init = _my_info_init,
)

should get documented as something like


MyInfo

This is my provider

MyInfo(a, c)

MyInfo constructor

CONSTRUCTOR PARAMETERS

Name Description Default Value
a Value of field a none
c Value to frobnicate "hello"

FIELDS

Name Description
a Field a
b Field b (frobnicated)

This is a prerequisite for switching to stardoc / starlark_doc_extract for generating Bazel's own documentation.

@tetromino tetromino self-assigned this Aug 16, 2023
copybara-service bot pushed a commit to bazelbuild/bazel that referenced this issue Aug 22, 2023
…cted docs

Note that init's signature may have little relation to the list of fields of
the constructed provider, so exposing a full StarlarkFunctionInfo for the init
is appropriate.

Working towards bazelbuild/stardoc#182

PiperOrigin-RevId: 559112284
Change-Id: I5a4821cde492676553a40400ff1e7831a069294f
tetromino added a commit to tetromino/stardoc that referenced this issue May 20, 2024
If a provider has a custom `init` callback, we want the summary blurb
to show `init`'s parameters (since these are what the user will interact
with); we have to render constructor paramaters and fields separately
(and using separate html anchors) since there is not necessarily a 1-1
relationship between them, and since they may have different docs.

Fixes bazelbuild#182
tetromino added a commit that referenced this issue May 22, 2024
By default, we want the following behavior:

* Custom init callback specified
  * The set of parameters for the init callback equals the set of
    fields for the provider; and the docs for the init callback's
    parameters are either empty or equal to corresponding field docs
    * Some init parameters have a default value:
      -> Render a single "Fields" table with 3 columns (name, doc,
         default value)
    * ... otherwise
      -> Render a single "Fields" table with 2 columns
  * ... otherwise
    -> Render two tables - "Constructor parameters" and "Fields" - with
       the links from the summary blurb (interfixed with "_init")
       leading to the parameters table (not the fields table)
* ... otherwise
  -> Trivial case - single "Fields" table (as before).

Fixes #182
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant