xref: /aosp_15_r20/external/bazelbuild-rules_python/examples/pip_parse_vendored/WORKSPACE (revision 60517a1edbc8ecf509223e9af94a7adec7d736b8)
1workspace(name = "pip_parse_vendored_example")
2
3local_repository(
4    name = "rules_python",
5    path = "../..",
6)
7
8load("@rules_python//python:repositories.bzl", "py_repositories", "python_register_toolchains")
9
10py_repositories()
11
12python_register_toolchains(
13    name = "python39",
14    python_version = "3.9",
15)
16
17load("@rules_python//python:pip.bzl", "pip_parse")
18
19# This repository isn't referenced, except by our test that asserts the requirements.bzl is updated.
20# It also wouldn't be needed by users of this ruleset.
21# If you're using envsubst with extra_pip_args, as we do below, the value of the environment
22# variables at the time we generate requirements.bzl don't make it into the file, as you may
23# verify by inspection; the environment variables at a later time, when we download the
24# packages, will be the ones that take effect.
25pip_parse(
26    # We choose a unique name here to make sure we can do some cleanup on it.
27    name = "pip_deps_to_be_vendored",
28    envsubst = ["PIP_RETRIES"],
29    extra_pip_args = ["--retries=${PIP_RETRIES:-5}"],
30    python_interpreter_target = "@python39_host//:python",
31    requirements_lock = "//:requirements.txt",
32)
33
34# This example vendors the file produced by `pip_parse` above into the repo.
35# This way our Bazel doesn't eagerly fetch and install the pip_parse'd
36# repository for builds that don't need it.
37# See discussion of the trade-offs in the pip_parse documentation
38# and the "vendor_requirements" target in the BUILD file.
39load("//:requirements.bzl", "install_deps")
40
41install_deps()
42