Common useful functions and rules for Bazel
Go to file
Alexandre Rostovtsev 6e30a77347
Update internal dependencies to modern versions. Bazel Federation repo is deprecated. (#327)
See https://github.com/bazelbuild/bazel-federation/pull/127

In particular, this allows us to use a modern Stardoc release to fix generated md docs.

And we can remove internal_deps.bzl/internal_setup.bzl - it's unnecessary complexity
needed only for deprecated Federation setup.
2021-10-27 09:13:59 -04:00
.bazelci Remove flag --incompatible_remap_main_repo (#227) 2020-01-16 10:34:47 +01:00
distribution Fix buildifier issue failing on CI. (#234) 2020-02-18 13:00:50 -05:00
docs Update internal dependencies to modern versions. Bazel Federation repo is deprecated. (#327) 2021-10-27 09:13:59 -04:00
gazelle/bzl Handle "internal" directory visibility (#274) 2020-10-21 23:52:14 -06:00
lib Improve escaping in unittest failure message (#320) 2021-10-04 12:03:48 -04:00
rules Use more portable `#!/usr/bin/env bash` shebang instead of hardcoded /bin/bash. (#329) 2021-10-25 09:12:41 -04:00
tests Use more portable `#!/usr/bin/env bash` shebang instead of hardcoded /bin/bash. (#329) 2021-10-25 09:12:41 -04:00
toolchains/unittest Improve escaping in unittest failure message (#320) 2021-10-04 12:03:48 -04:00
.gitignore Add initial .gitignore with bazel-* folders 2017-10-31 07:04:27 -07:00
AUTHORS Fix grammar. 2018-02-20 16:53:50 -05:00
BUILD Update internal dependencies to modern versions. Bazel Federation repo is deprecated. (#327) 2021-10-27 09:13:59 -04:00
CHANGELOG.md Missing version number bump in version.bzl for the new release (#318) 2021-09-27 13:12:59 -04:00
CODEOWNERS update owners (#289) 2021-01-29 13:38:17 -05:00
CONTRIBUTING.md Initial check-in. 2017-10-10 07:59:31 -07:00
CONTRIBUTORS add cparsons and bttk to the CONTRIBUTORS file (#73) 2018-11-20 15:19:06 -05:00
LICENSE Initial check-in. 2017-10-10 07:59:31 -07:00
README.md Fix default branch name in README (#292) 2021-05-13 10:22:43 -04:00
WORKSPACE Update internal dependencies to modern versions. Bazel Federation repo is deprecated. (#327) 2021-10-27 09:13:59 -04:00
bzl_library.bzl Migrate code for the flag --incompatible_disable_depset_items (#232) 2020-02-03 16:45:44 +01:00
lib.bzl `print`->`fail` and suppress the warning in another case. (#177) 2019-07-22 13:25:00 -04:00
skylark_library.bzl `print`->`fail` and suppress the warning in another case. (#177) 2019-07-22 13:25:00 -04:00
version.bzl Missing version number bump in version.bzl for the new release (#318) 2021-09-27 13:12:59 -04:00
workspace.bzl add missing license notices (#94) 2019-01-14 16:00:11 -05:00

README.md

Skylib

Build status

Skylib is a library of Starlark functions for manipulating collections, file paths, and various other data types in the domain of Bazel build rules.

Each of the .bzl files in the lib directory defines a "module"—a struct that contains a set of related functions and/or other symbols that can be loaded as a single unit, for convenience.

Skylib also provides build rules under the rules directory.

Getting Started

WORKSPACE file

See the WORKSPACE setup section for the current release.

If you want to use lib/unittest.bzl from Skylib versions released in or after December 2018, then you also should add to the WORKSPACE file:

load("@bazel_skylib//:workspace.bzl", "bazel_skylib_workspace")

bazel_skylib_workspace()

BUILD and *.bzl files

Then, in the BUILD and/or *.bzl files in your own workspace, you can load the modules (listed below) and access the symbols by dotting into those structs:

load("@bazel_skylib//lib:paths.bzl", "paths")
load("@bazel_skylib//lib:shell.bzl", "shell")

p = paths.basename("foo.bar")
s = shell.quote(p)

List of modules (in lib/)

List of rules (in rules/)

Writing a new module

The criteria for adding a new function or module to this repository are:

  1. Is it widely needed? The new code must solve a problem that occurs often during the development of Bazel build rules. It is not sufficient that the new code is merely useful. Candidate code should generally have been proven to be necessary across several projects, either because it provides indispensible common functionality, or because it requires a single standardized implementation.

  2. Is its interface simpler than its implementation? A good abstraction provides a simple interface to a complex implementation, relieving the user from the burden of understanding. By contrast, a shallow abstraction provides little that the user could not easily have written out for themselves. If a function's doc comment is longer than its body, it's a good sign that the abstraction is too shallow.

  3. Is its interface unimpeachable? Given the problem it tries to solve, does it have sufficient parameters or generality to address all reasonable cases, or does it make arbitrary policy choices that limit its usefulness? If the function is not general, it likely does not belong here. Conversely, if it is general thanks only to a bewildering number of parameters, it also does not belong here.

  4. Is it efficient? Does it solve the problem using the asymptotically optimal algorithm, without using excessive looping, allocation, or other high constant factors? Starlark is an interpreted language with relatively expensive basic operations, and an approach that might make sense in C++ may not in Starlark.

If your new module meets all these criteria, then you should consider sending us a pull request. It is always better to discuss your plans before executing them.

Many of the declarations already in this repository do not meet this bar.

Steps to add a module to Skylib:

  1. Create a new .bzl file in the lib directory.

  2. Write the functions or other symbols (such as constants) in that file, defining them privately (prefixed by an underscore).

  3. Create the exported module struct, mapping the public names of the symbols to their implementations. For example, if your module was named things and had a function named manipulate, your things.bzl file would look like this:

    def _manipulate():
      ...
    
    things = struct(
        manipulate=_manipulate,
    )
    
  4. Add unit tests for your module in the tests directory.

bzl_library

The bzl_library.bzl rule can be used to aggregate a set of Starlark files and its dependencies for use in test targets and documentation generation.

Troubleshooting

If you try to use unittest and you get the following error:

ERROR: While resolving toolchains for target //foo:bar: no matching toolchains found for types @bazel_skylib//toolchains:toolchain_type
ERROR: Analysis of target '//foo:bar' failed; build aborted: no matching toolchains found for types @bazel_skylib//toolchains:toolchain_type

then you probably forgot to load and call bazel_skylib_workspace() in your WORKSPACE file.