[feature request] Consider moving `bzl_library.bzl` into `@bazel_tools`

[jmillikin]

Description of the feature request:

Skylib's bzl_library.bzl provides a StarlarkLibraryInfo provider and bzl_library rule, which are used for aggregating .bzl rules files for use by other analysis tools.

The definition of that provider and rule are quite stable (basically unchanged since 2018), and it has no dependencies on any other part of skylib.

The natural way to use that file is to load it from every BUILD file in a ruleset, like this:

# rules_example/example/BUILD
load("@bazel_skylib//:bzl_library.bzl", "bzl_library")

bzl_library(
    name = "bzl_srcs",
    srcs = ["defs.bzl", "repository.bzl", "toolchain.bzl"],
    deps = ["//example/internal:bzl_srcs"],
)

However, since the load needs to fetch skylib before evaluation continues, this means that skylib becomes a hard dependency for every client of the ruleset.

Given that the bzl_library.bzl file is generic, broadly useful, and very stable, could it be bundled into @bazel_tools instead?

[comius]

cc @aiuto @brandjon
This was discussed before. What were the conclusion, should we do it?

[comius]

@brandjon please triage

[aiuto]

IIRC, the discussion just sort of faded away.

I would like to seeStarlarkLibraryInfo and maybe bzl_library shipped with Bazel. But I also want the ability to replace the implementation of each with a repository local one. While trying to create another ultra low-level part of the stack (rules_license), what I have found that I want is the ability to locally override individual files in @bazel_tools. For example, I want to be able to replace http_archive at the workspace level, even if others are loading from @bazel_tools

Currently I am at a split opinion here. StarlarkLibraryInfo is a fundamental constant, because Stardoc breaks unless everyone depends on the same instance of it, so moving it to @bazel_tools does seem right (in spite of our desire to prune tools). bzl_library I would like to be able to override locally without having to vendor in all skylib.

But writing this helped me clarify a thought. What I want to be able to declare is a workspace wide replacement for the path of any load(). That way I could create my own http_archive or bzl_library without having to completely replace skylib or tools.

[fmeum]

Instead of moving bzl_library into bazel_tools, how about moving it into a separate repo that doesn't contain anything else and just remains lightweight forever?

Skylib could add this repo to its dependencies and continue to forward the provider for backwards compatibility.