Jon Brandvein

Hi @lisaonduty, Sorry for the delay in a response to this and other issues you've filed. At the moment we have [plans](https://github.com/bazelbuild/stardoc/blob/b0fb1463b546557c11b2e01cc20d14e551cc718c/docs/future_plans.md) to rework how Stardoc integrates with Bazel so...

Hi @UebelAndre, see #89 and in particular [Prioritization](https://github.com/bazelbuild/stardoc/blob/b0fb1463b546557c11b2e01cc20d14e551cc718c/docs/future_plans.md#prioritization). We won't be working on new features in the immediate future.

I think with #69 it'll be moot anyway. I imagine you'd effectively be querying the documentation of a bzl file by giving its label, regardless of visibility.

What I was getting at was that you'd end up generating a file (a la genquery) that includes extracted documentation, and that file would become the input to the rendering...

We'd only want the actual extraction to be built into Bazel. What you do with that information in terms of rendering, resolving labels to hyperlinks, etc., should be customizable and...

That sounds like a nice feature. It might not be applicable in all environments since the repo might be imported by a different non-standard name in the user's WORKSPACE file,...

See #69, this should be addressed when we rewrite the doc extraction to grab real objects from the loading phase instead of mocking it in a separate process.

(P4ing this one as opposed to marking it a dup, but the underlying rewrite is actually a P1 FR that we're aiming to work on this quarter and next.)

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....

> The main reason of this approach is to separate the project dependencies from the documentation dependencies as well as to have the capabilities to document multiple projects at once....