Transitive dependencies on @bazel_tools make it impossible to use Stardoc

[c-parsons]

Currently there's no bzl_libary targets for @bazel_tools, because, well, bzl_libary is defined in bazel-skylib, and @bazel_tools is essentially native.
This means that a transitive dependency on @bazel_tools will be impossible to resolve.

Proposal: bazel-skylib defines core bzl_library targets for the full contents of @bazel_tools, and then Stardoc targets depend on these libraries by default.

(Ideally, the bzl_library targets responsible for the direct dependency would declare the dependency, but I think it's safe to pull in bazel's core libraries default for ease of use)

[qzmfranklin]

Vote on this issue being looked up.

This is especially inconvenient as more and more native rules are migrated to starlark.

For example, even http_archive is now loaded from @bazel_tools. Any macros or rules depending on http_archive cannot have generated docs because of this issue.

[long-stripe]

Registering my interest in this being fixed!

We'd love to use Stardoc to document bazelbuild/rules_scala but are currently blocked by this very problem: bazelbuild/rules_scala#133 (comment).

[vmax]

We at @graknlabs managed to work around this issue by explicitly adding bazel's execution root to depRoots which makes is possible to resolve external/bazel_tools/…. For anybody interested: https://github.com/graknlabs/skydoc/tree/experimental-skydoc-allow-dep-on-bazel-tools

[brandjon]

This is hitting me when trying to fix rules_python's docgen.

I can fix this by adding exports_files declarations for these bzls to Bazel, but that would be delayed by a Bazel release. Also, I'd have to export any internal .bzls that these ones load, whereas with bzl_library you can normally keep internal .bzls private (w.r.t. target dependencies, not loading). The latter issue could be addressed by modifying skylib's bzl_library to recognize a version of itself that is vendored into @bazel_tools. That is, the rule definition and StarlarkLibraryInfo could be copied into @bazel_tools and the real bzl_library in skylib could permit that provider in its dependencies as well.

[deeglaze]

This is also impacting the Asylo project's use of skydoc. Our asylo_deps.bzl file cannot have generated documentation due to the dependence on @bazel_tools//tools/build_defs/repo:http.bzl. The bzl_library target [...]/repo:lib appears to not be accessible to depend on.

[c-parsons]

For Bazel 1.0, we export all Starlark files under @bazel_tools. As a result, you should be able to create bzl_library targets which import relevant Starlark files, and then depend on these bzl_library targets form your stardoc target.

[deeglaze]

I don't think this is fixed due to the visibility of each bzl_srcs target not being public except for @bazel_tools//tools:bzl_srcs, which is a filegroup. The filegroup does not have a StarlarkLibraryInfo provider, so I still can't build my documentation.

ERROR: /opt/asylo/docs/asylo/docs/BUILD:62:1: in deps attribute of stardoc rule //asylo/docs:sgx_deps_bzl-docs: '@bazel_tools//tools/build_defs/repo:bzl_srcs' does not have mandatory providers: 'StarlarkLibraryInfo'

[brandjon]

IIUC, instead of depending on bzl_srcs directly in the deps of a bzl_library, you should be able to define your own bzl_library which includes this filegroup under srcs.