)]}' { "commit": "966f002d896a9ba16d4b673e6faf14bf69facd60", "tree": "897a286d22c8bf35cf722489c7ff11742248e9f7", "parents": [ "3773b603ff6d3c02531cbdd4a3081ea23eb2001c" ], "author": { "name": "Ted Kaplan", "email": "ted.kaplan@bedrockrobotics.com", "time": "Wed Oct 07 02:33:18 2026 +0000" }, "committer": { "name": "GitHub", "email": "noreply@github.com", "time": "Wed Oct 07 02:33:18 2026 +0000" }, "message": "feat(pypi): generate requirements.bzl in the unified @pypi hub (#4223)\n\nThe unified `@pypi` hub (#3837) does not generate a `requirements.bzl`.\nThat makes renaming a hub away from the now-reserved `pypi` name an\nall-at-once change: the moment the concrete hub stops being `@pypi`,\nevery `load(\"@pypi//:requirements.bzl\", \"requirement\")` in the repo\nfails to load. In our monorepo that is ~940 BUILD files, and any BUILD\nfile that lands on main mid-migration re-breaks it. The same thing would\nhappen to every such repo if `RULES_PYTHON_PYPI_HUB_RESERVED` is flipped\non by default, as discussed in #3837.\n\nThis adds an opt-in, `pip.default(unified_hub_requirements_bzl \u003d True)`\n(root module only, off by default), that generates a `requirements.bzl`\nin the unified hub with the per-package macros of a concrete hub\u0027s. It\u0027s\nopt-in because the docs already steer users to `@pypi//\u003cpkg\u003e` labels\nover `requirement()`; this is a migration aid for repos whose hub used\nto be named `pypi`, not a new default surface. With it on:\n\n* `requirement()`, `whl_requirement()`, `data_requirement()` and\n`dist_info_requirement()` return labels in the unified hub\n(`@@\u003cunified\u003e//\u003cpkg\u003e:pkg` etc., the same canonical-name form the\nconcrete hubs use), so they route through\n`--@rules_python//python/config_settings:venv` exactly like a plain\n`@pypi//\u003cpkg\u003e` label. All of those targets already exist in every\nunified package (`_STANDARD_ALIASES`).\n* The `all_*` lists (`all_requirements`,\n`all_whl_requirements(_by_package)`, `all_data_requirements`) are\ndeliberately not generated. They are fixed at loading time, before the\nvenv flag is known, so they could only list one hub\u0027s packages and would\nsilently not follow the flag like the rest of the unified hub. Code that\nwants a whole lock loads them from that concrete hub, and a stale\n`load(\"@pypi//:requirements.bzl\", \"all_requirements\")` fails loudly\ninstead.\n\nBefore: after renaming `hub_name \u003d \"pypi\"` to e.g. `\"pypi_main\"` with\n`pip.default(default_hub \u003d \"pypi_main\")`,\n`load(\"@pypi//:requirements.bzl\", ...)` fails with \"no such file\".\nAfter, with the opt-in: it keeps working and resolves to the same\nwheels, and targets can migrate to `\"@pypi//\u003cpkg\u003e\"` labels incrementally\n(we\u0027re moving our own repo to labels and gating new `requirement()`\ncalls in CI). Without the opt-in nothing changes.\n\nTests:\n* `tests/pypi/extension`: the setting is off by default, on when the\nroot module sets it, and ignored from a non-root module.\n* `tests/integration/unified_pypi` (which now opts in): `requirement()`\nwith a non-normalized name on the default hub, `requirement()` under a\nvenv transition, and loading `@pypi//:requirements.bzl` failing once the\nopt-in is removed. Passes on `bazel_self` and `bazel_7.7.0`.\n\nContext: we\u0027re carrying this as a local patch in a large monorepo, where\nrenaming our main hub and loading `requirement` from the unified hub\nleaves the resolved wheel set unchanged. #4172 also touches\n`tests/integration/unified_pypi`; the two should merge independently,\nbut one of them may need a trivial rebase.\n\n(Done with help from an agent.)\n\n🤖 Generated with [Claude Code](https://claude.com/claude-code)\n\n---------\n\nCo-authored-by: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e", "tree_diff": [ { "type": "modify", "old_id": "e4ab38714d6151e1934b838c4faad4403937f6b4", "old_mode": 33188, "old_path": "docs/pypi/download.md", "new_id": "b9904d4071f1301622200e90acf7d8d6f55ca08e", "new_mode": 33188, "new_path": "docs/pypi/download.md" }, { "type": "add", "old_id": "0000000000000000000000000000000000000000", "old_mode": 0, "old_path": "/dev/null", "new_id": "de37e0e0e33a165eb7f4ddf4ad4aa0f1d539ad24", "new_mode": 33188, "new_path": "news/4223.added.md" }, { "type": "modify", "old_id": "cafe245eb26b12eb5cc556f03138037d63c3370e", "old_mode": 33188, "old_path": "python/private/pypi/extension.bzl", "new_id": "1b827806f20d3b9e94cc705d56239beb1680e367", "new_mode": 33188, "new_path": "python/private/pypi/extension.bzl" }, { "type": "modify", "old_id": "f88db75f19d3c2d3063fadcddd88520d70aa9204", "old_mode": 33188, "old_path": "python/private/pypi/unified_hub_repo.bzl", "new_id": "ddd15c0d8685d1b259faa59207f366484eb0a76f", "new_mode": 33188, "new_path": "python/private/pypi/unified_hub_repo.bzl" }, { "type": "modify", "old_id": "c0b9905fa63de63ef1275fdf5d1d1d02bf20b33a", "old_mode": 33188, "old_path": "tests/integration/unified_pypi/BUILD.bazel", "new_id": "c0aee2de5d6922bb2ae811c0fa9d652ea1b7b7cf", "new_mode": 33188, "new_path": "tests/integration/unified_pypi/BUILD.bazel" }, { "type": "modify", "old_id": "6a4b87e015e7c578839387bd96d86fb7c6550a2e", "old_mode": 33188, "old_path": "tests/integration/unified_pypi/MODULE.bazel", "new_id": "6dd2e25dd5c725216a411d52d34edfff45a5f403", "new_mode": 33188, "new_path": "tests/integration/unified_pypi/MODULE.bazel" }, { "type": "modify", "old_id": "a19a9fcfbe4718c90dfcffe7f15685b4f8abfd00", "old_mode": 33188, "old_path": "tests/integration/unified_pypi_test.py", "new_id": "08f7b029c18efe7bb9c2472c6c6fe4d228942224", "new_mode": 33188, "new_path": "tests/integration/unified_pypi_test.py" }, { "type": "modify", "old_id": "97849e882d5b945036ca7e55dba568920aeb0567", "old_mode": 33188, "old_path": "tests/pypi/extension/extension_tests.bzl", "new_id": "6d7e971132617ad5688741db6b3c114fd0865b0a", "new_mode": 33188, "new_path": "tests/pypi/extension/extension_tests.bzl" } ] }