compile_pip_requirements

Generates targets for managing pip dependencies with pip-compile.

By default this rules generates a filegroup named “[name]” which can be included in the data of some other compile_pip_requirements rule that references these requirements (e.g. with -r ../other/requirements.txt).

It also generates two targets for running pip-compile:

  • validate with bazel test <name>_test
  • update with bazel run <name>.update

PARAMETERS

NameDescriptionDefault Value
namebase name for generated targets, typically “requirements”none
extra_argspassed to pip-compile[]
visibilitypassed to both the _test and .update rules[“//visibility:private”]
requirements_infile expressing desired dependenciesNone
requirements_txtresult of “compiling” the requirements.in fileNone
tagstagging attribute common to all build rules, passed to both the _test and .update rulesNone
kwargsother bazel attributes passed to the “_test” rulenone

package_annotation

Annotations to apply to the BUILD file content from package generated from a pip_repository rule.

PARAMETERS

NameDescriptionDefault Value
additive_build_contentRaw text to add to the generated BUILD file of a package.None
copy_filesA mapping of src and out files for @bazel_skylib//rules:copy_file.bzl{}
copy_executablesA mapping of src and out files for @bazel_skylib//rules:copy_file.bzl. Targets generated here will also be flagged as executable.{}
dataA list of labels to add as data dependencies to the generated py_library target.[]
data_exclude_globA list of exclude glob patterns to add as data to the generated py_library target.[]
srcs_exclude_globA list of labels to add as srcs to the generated py_library target.[]

pip_install

Accepts a requirements.txt file and installs the dependencies listed within.

Those dependencies become available in a generated requirements.bzl file.

This macro wraps the pip_repository rule that invokes pip. In your WORKSPACE file:

pip_install(
    requirements = ":requirements.txt",
)

You can then reference installed dependencies from a BUILD file with:

load("@pip//:requirements.bzl", "requirement")
py_library(
    name = "bar",
    ...
    deps = [
       "//my/other:dep",
       requirement("requests"),
       requirement("numpy"),
    ],
)

Note that this convenience comes with a cost. Analysis of any BUILD file which loads the requirements helper in this way will cause an eager-fetch of all the pip dependencies, even if no python targets are requested to be built. In a multi-language repo, this may cause developers to fetch dependencies they don't need, so consider using the long form for dependencies if this happens.

In addition to the requirement macro, which is used to access the py_library target generated from a package's wheel, the generated requirements.bzl file contains functionality for exposing entry points as py_binary targets.

load("@pip_deps//:requirements.bzl", "entry_point")

alias(
    name = "pip-compile",
    actual = entry_point(
        pkg = "pip-tools",
        script = "pip-compile",
    ),
)

Note that for packages whose name and script are the same, only the name of the package is needed when calling the entry_point macro.

load("@pip_deps//:requirements.bzl", "entry_point")

alias(
    name = "flake8",
    actual = entry_point("flake8"),
)

PARAMETERS

NameDescriptionDefault Value
requirementsA ‘requirements.txt’ pip requirements file.None
nameA unique name for the created external repository (default ‘pip’).“pip”
kwargsAdditional arguments to the pip_repository repository rule.none

pip_parse

Accepts a locked/compiled requirements file and installs the dependencies listed within.

Those dependencies become available in a generated requirements.bzl file. You can instead check this requirements.bzl file into your repo, see the “vendoring” section below.

This macro wraps the pip_repository rule that invokes pip, with incremental set. In your WORKSPACE file:

load("@rules_python//python:pip.bzl", "pip_parse")

pip_parse(
    name = "pip_deps",
    requirements_lock = ":requirements.txt",
)

load("@pip_deps//:requirements.bzl", "install_deps")

install_deps()

You can then reference installed dependencies from a BUILD file with:

load("@pip_deps//:requirements.bzl", "requirement")

py_library(
    name = "bar",
    ...
    deps = [
       "//my/other:dep",
       requirement("requests"),
       requirement("numpy"),
    ],
)

In addition to the requirement macro, which is used to access the generated py_library target generated from a package's wheel, The generated requirements.bzl file contains functionality for exposing entry points as py_binary targets as well.

load("@pip_deps//:requirements.bzl", "entry_point")

alias(
    name = "pip-compile",
    actual = entry_point(
        pkg = "pip-tools",
        script = "pip-compile",
    ),
)

Note that for packages whose name and script are the same, only the name of the package is needed when calling the entry_point macro.

load("@pip_deps//:requirements.bzl", "entry_point")

alias(
    name = "flake8",
    actual = entry_point("flake8"),
)

Vendoring the requirements.bzl file

In some cases you may not want to generate the requirements.bzl file as a repository rule while Bazel is fetching dependencies. For example, if you produce a reusable Bazel module such as a ruleset, you may want to include the requirements.bzl file rather than make your users install the WORKSPACE setup to generate it. See https://github.com/bazelbuild/rules_python/issues/608

This is the same workflow as Gazelle, which creates go_repository rules with update-repos

To do this, use the “write to source file” pattern documented in https://blog.aspect.dev/bazel-can-write-to-the-source-folder to put a copy of the generated requirements.bzl into your project. Then load the requirements.bzl file directly rather than from the generated repository. See the example in rules_python/examples/pip_parse_vendored.

PARAMETERS

NameDescriptionDefault Value
requirements_lockA fully resolved ‘requirements.txt’ pip requirement file containing the transitive set of your dependencies. If this file is passed instead of ‘requirements’ no resolve will take place and pip_repository will create individual repositories for each of your dependencies so that wheels are fetched/built only for the targets specified by ‘build/run/test’. Note that if your lockfile is platform-dependent, you can use the requirements_[platform] attributes.none
nameThe name of the generated repository. The generated repositories containing each requirement will be of the form <name>_<requirement-name>.“pip_parsed_deps”
kwargsAdditional arguments to the pip_repository repository rule.none