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

Should not require rules to aliased before being documented #94

Open
shs96c opened this issue Mar 11, 2021 · 3 comments
Open

Should not require rules to aliased before being documented #94

shs96c opened this issue Mar 11, 2021 · 3 comments

Comments

@shs96c
Copy link

shs96c commented Mar 11, 2021

When following the instructions for documenting multiple files the generated docs are empty. In order for content to be created, the rules need to aliased in some way.

That is, attempting to generate docs from the following will lead to an empty doc:

load("//foo:foo.bzl", "foo_rule")
load("//bar:bar.bzl", "bar_rule")
load("//baz:baz.bzl", "baz_rule")

Whereas:

load("//foo:foo.bzl", _foo_rule = "foo_rule")
load("//bar:bar.bzl", _bar_rule = "bar_rule")
load("//baz:baz.bzl", _baz_rule = "baz_rule")

foo_rule = _foo_rule
bar_rule = _bar_rule
baz_rule = _baz_rule

will lead to the expected documentation being generated. This is confusing and unexpected. In addition, many authors don't want to expose all the rules this way.

@brandjon
Copy link
Member

This is because loaded symbols are private to the file that loads them, unlike assigned global variables which are considered part of the module object defined by the .bzl file. So they're invisible to Stardoc.

This will still be the case even after the rewrite of Stardoc to use a bazel query style approach.

What I wonder is why are you loading these symbols if you don't also want to export them. I'd suggest that either you continue to assign _foo_rule to foo_rule, so that this .bzl file becomes both a public entry point to load and also a place to point stardoc; or else you instead point stardoc at foo.bzl, bar.bzl, etc.

@Kernald
Copy link

Kernald commented Aug 18, 2021

What I wonder is why are you loading these symbols if you don't also want to export them. I'd suggest that either you continue to assign _foo_rule to foo_rule, so that this .bzl file becomes both a public entry point to load and also a place to point stardoc; or else you instead point stardoc at foo.bzl, bar.bzl, etc.

The current stardoc rule only allows for one input file, doesn't it? It sometimes makes sense exposing multiple rules/macros in a single documentation page. I just hit the same issue trying to do just that. I'm not sure it's a totally legitimate use-case as I'm not entirely sure what I want to do with those docs, and maybe I don't want to do it this way, but that's how I encountered this issue as well. As a sidenote, the documentation should at least be updated to reflect this.

@tetromino
Copy link
Collaborator

The current stardoc rule only allows for one input file, doesn't it? It sometimes makes sense exposing multiple rules/macros in a single documentation page.

This is difficult to do well in the general case.

  • Each .bzl file will have its own module docstring at the top of the file. How do you render those multiple docstrings in a single markdown file in a way that is not confusing?
  • How do you inform your reader which symbol is exported by which .bzl file?
  • How do you handle aliasing, where the same symbol is exported by two different .bzl files under different names?

And if you don't want to do it well in the general case, if your use case is very simple, you can just write a genrule to concatenate the markdown output of two stardoc rules :)

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

No branches or pull requests

4 participants