Name | Date | Size | #Lines | LOC | ||
---|---|---|---|---|---|---|
.. | - | - | ||||
.bazelrc | H A D | 25-Apr-2025 | 270 | 9 | 6 | |
.gitignore | H A D | 25-Apr-2025 | 8 | 2 | 1 | |
BUILD.bazel | H A D | 25-Apr-2025 | 2.6 KiB | 77 | 69 | |
README.md | H A D | 25-Apr-2025 | 1.1 KiB | 32 | 23 | |
WORKSPACE | H A D | 25-Apr-2025 | 1.5 KiB | 42 | 33 | |
requirements.bzl | H A D | 25-Apr-2025 | 5 KiB | 117 | 96 | |
requirements.in | H A D | 25-Apr-2025 | 89 | 3 | 2 | |
requirements.txt | H A D | 25-Apr-2025 | 1.2 KiB | 29 | 28 | |
test_dependency_usage.py | H A D | 25-Apr-2025 | 197 | 13 | 7 |
README.md
1# pip_parse vendored 2 3This example is like pip_parse, however we avoid loading from the generated file. 4See https://github.com/bazelbuild/rules_python/issues/608 5and https://blog.aspect.dev/avoid-eager-fetches. 6 7The requirements now form a triple: 8 9- requirements.in - human editable, expresses only direct dependencies and load-bearing version constraints 10- requirements.txt - lockfile produced by pip-compile or other means 11- requirements.bzl - the "parsed" version of the lockfile readable by Bazel downloader 12 13The `requirements.bzl` file contains baked-in attributes such as `python_interpreter_target` as they were specified in the original `pip_parse` rule. These can be overridden at install time by passing arguments to `install_deps`. For example: 14 15```python 16# Register a hermetic toolchain 17load("@rules_python//python:repositories.bzl", "python_register_toolchains") 18 19python_register_toolchains( 20 name = "python39", 21 python_version = "3.9", 22) 23load("@python39//:defs.bzl", "interpreter") 24 25# Load dependencies vendored by some other ruleset. 26load("@some_rules//:py_deps.bzl", "install_deps") 27 28install_deps( 29 python_interpreter_target = interpreter, 30) 31``` 32