commit | 4725d98a3a53ebf90c45d29245691fa060f9c734 | [log] [tgz] |
---|---|---|
author | Reid D McKenzie <me@arrdem.com> | Tue Nov 28 11:03:01 2023 -0700 |
committer | GitHub <noreply@github.com> | Tue Nov 28 18:03:01 2023 +0000 |
tree | 44e6d11e286da8d43d48905663b293df59aa1388 | |
parent | 69abe80724c8ef353fec3d59e578e949dad540a0 [diff] |
feat(pip_repository): Support pip parse cycles (#1166) This patch reworks the `pip_repository` machinery to allow users to manually annotate groups of libraries which form packaging cycles in PyPi and must be simultaneously installed. The strategy here is to transform any dependencies `A` and `B` which have dependencies and are mutually dependent ```mermaid graph LR; A-->B; A-->D; A-->E; B-->A; B-->F; B-->G; ``` into a new "dependency group" `C` which has `A*` and `B*` as dependencies, defined as `A` and `B` less any direct dependencies which are members of the group. This is viable _for python_ because Python files just need to be emplaced into a runfiles directory for the interpreter. We don't actually have a true hard dependency between the build definition of `A` requiring the build product `B` be available which requires that the build product of `A` be available. ```mermaid graph LR C-->A*; A*-->D; A*-->E; C-->B*; B*-->F; B*-->G; ``` This gets us most of the way there, as a user can now safely write `requirement("A")` and we can provide them with `C`, which has the desired effect of pulling in `A`, `B` and their respective transitives. There is one remaining problem - a user writing `deps = [requirement("A"), requirement("B")]` will take a double direct dependency on `C`. So we need to insert a layer of indirection, generating `C_A` and `C_B` which serve only as unique aliases for `C` so that we can support the double dependency. Our final dependency graph then is as follows ```mermaid graph LR C_A-->C; C_B-->C; C-->A*; A*-->D; A*-->E; C-->B*; B*-->F; B*-->G; ``` Addresses #1076, #1188 ## To do - [x] Get rebased - [x] Get re-validated manually - [x] Buildifier - [x] Get CI happy - [x] Update documentation - [x] Update changelog --------- Co-authored-by: Ignas Anikevicius <240938+aignas@users.noreply.github.com>
This repository is the home of the core Python rules -- py_library
, py_binary
, py_test
, py_proto_library
, and related symbols that provide the basis for Python support in Bazel. It also contains package installation rules for integrating with PyPI and other indices.
Documentation for rules_python is at https://rules-python.readthedocs.io and in the Bazel Build Encyclopedia.
Examples live in the examples directory.
Currently, the core rules build into the Bazel binary, and the symbols in this repository are simple aliases. However, we are migrating the rules to Starlark and removing them from the Bazel binary. Therefore, the future-proof way to depend on Python rules is via this repository. SeeMigrating from the Bundled Rules
below.
The core rules are stable. Their implementation in Bazel is subject to Bazel's backward compatibility policy. Once migrated to rules_python, they may evolve at a different rate, but this repository will still follow semantic versioning.
The Bazel community maintains this repository. Neither Google nor the Bazel team provides support for the code. However, this repository is part of the test suite used to vet new Bazel releases. See How to contribute page for information on our development workflow.
For detailed documentation, see https://rules-python.readthedocs.io
See Bzlmod support for more details.