unnatural_designs/MODULE.bazel at main · Syndic/unnatural_designs · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
module(
    name = "unnatural_designs",
    version = "0.0.0",
)

# ── Platforms ─────────────────────────────────────────────────────────────────────────────────────
# Standard OS/CPU constraints used by //platforms:*.
bazel_dep(name = "platforms", version = "1.1.0")

# ── BuildBuddy remote execution ───────────────────────────────────────────────────────────────────
# Provides exec-platform definitions (linux_x86_64, linux_arm64) and CC toolchains for BB's
# remote executors. The use_extension call materialises the @toolchains_buildbuddy repo so
# its platform labels resolve when referenced from .bazelrc. We deliberately do NOT call
# register_execution_platforms here: a global registration would make BB's linux platforms
# candidate exec platforms on the darwin_arm64 CI runner too. ijar (a Bazel-internal C++
# tool) has no exec_compatible_with constraints, so Bazel would pick a linux exec platform
# first, then fail to find a cpp toolchain (the darwin host only has its own auto-detected
# cpp toolchain). Instead, .bazelrc adds the matching BB platform via
# --extra_execution_platforms on each --config=linux_* so it's only a candidate when we're
# actually targeting linux. See https://www.buildbuddy.io/blog/arm64-support/ for the arm64
# rollout that motivated this.
bazel_dep(name = "toolchains_buildbuddy", version = "0.0.4")

buildbuddy = use_extension("@toolchains_buildbuddy//:extensions.bzl", "buildbuddy")

# ── Go ────────────────────────────────────────────────────────────────────────────────────────────
bazel_dep(name = "rules_go", version = "0.62.0")
bazel_dep(name = "gazelle", version = "0.52.2")

go_sdk = use_extension("@rules_go//go:extensions.bzl", "go_sdk")

# Download the SDK for each platform we may execute Go actions on. A single
# download tag carrying only a version (no goos/goarch) downloads only the host
# SDK, which breaks `--config=remote_bb` from a darwin host: BuildBuddy executors are
# linux_amd64 and would receive the darwin SDK ("cannot execute binary file: Exec
# format error" on the GoToolchainBinaryBuild action). Listing each platform
# explicitly registers a toolchain per exec_compatible_with, and rules_go selects
# the matching one when the exec platform is resolved.
#
# Renovate's regex matcher in renovate.json picks up each occurrence; bumps will
# arrive as one grouped PR ("Language toolchain SDKs") keeping all three in sync.
go_sdk.download(
    goarch = "amd64",
    goos = "linux",
    version = "1.26.5",
)
go_sdk.download(
    goarch = "arm64",
    goos = "linux",
    version = "1.26.5",
)
go_sdk.download(
    goarch = "arm64",
    goos = "darwin",
    version = "1.26.5",
)

# Discover external Go deps from the workspace's go.work + per-module go.mod files.
go_deps = use_extension("@gazelle//:extensions.bzl", "go_deps")
go_deps.from_file(go_work = "//:go.work")

# use_repo entries below are managed by `bazel mod tidy` — run that after
# adding or removing an external Go import; do not hand-edit.
use_repo(go_deps, "com_github_vbauerster_mpb_v8")

# ── Python ────────────────────────────────────────────────────────────────────────────────────────
bazel_dep(name = "rules_python", version = "2.2.0")

python = use_extension("@rules_python//python/extensions:python.bzl", "python")
python.toolchain(
    # Wires the bundled `coverage` library into py_test runfiles when
    # `bazel coverage` runs, so Python tests emit lcov data alongside Go.
    configure_coverage_tool = True,
    python_version = "3.14",
)

# Materialise the third-party Python deps locked by uv. The chain is:
#   pyproject.toml  →  uv.lock  →  requirements_lock.txt  →  pip.parse  →  @unnatural_designs_pypi//...
# uv.lock is the source of truth; requirements_lock.txt is its `uv export`
# projection (pip.parse still requires a requirements.txt-format input — see
# `docs/future-considerations.md` "Drop requirements_lock.txt"). A pre-commit
# hook keeps the two in sync; see `uv-lock-fresh` in .pre-commit-config.yaml.
# The export deliberately keeps `--hash` entries: pip.parse uses them to verify
# the exact artifact uv resolved against. Without hashes it round-trips to
# PyPI's Simple API at fetch time and accepts any wheel ever uploaded under the
# pinned version — strictly weaker provenance for no gain.
pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip")
pip.parse(
    # Non-reserved hub name: rules_python reserves the bare "pypi" hub and warns it
    # will auto-rename to "<module>_pypi" in a future release, so we adopt that name now.
    hub_name = "unnatural_designs_pypi",
    python_version = "3.14",
    requirements_lock = "//:requirements_lock.txt",
)
use_repo(pip, "unnatural_designs_pypi")

# TEND(tooling): rules_python_gazelle_plugin (a.k.a. gazelle_python) is not wired
# here. The plugin's gazelle binary pulls in smacker/go-tree-sitter via CGO,
# which does not compile under our pinned Go SDK (upstream issue
# bazel-contrib/rules_python#3416; the migration to a pure-Go binding is in
# the unmerged bazel-contrib/rules_python#3786). Until #3786 ships in a
# release, Python BUILD files are hand-authored. See
# `docs/future-considerations.md` (Python BUILD generation) for the trigger
# that brings this back in.

# ── Container images ──────────────────────────────────────────────────────────────────────────────
# The shared devcontainer base image (//meta/devcontainer-base) is assembled here rather than by a
# Dockerfile so it rides `bazel build //...` like everything else — one command, exercised locally
# and in CI. rules_oci only *assembles* layers; it cannot execute a RUN step, which turns the
# image's deliberately RUN-free shape into a property of the toolchain instead of a convention
# someone has to honour. It also needs no Docker daemon to build, which matters because this
# repo's own devcontainer has neither a docker client nor a mounted socket.
bazel_dep(name = "rules_oci", version = "2.3.0")
bazel_dep(name = "rules_pkg", version = "1.2.0")

oci = use_extension("@rules_oci//oci:extensions.bzl", "oci")

# `tag` and `digest` together on purpose: the digest is what makes the fetch reproducible, and the
# tag is what Renovate's bazel-module manager anchors its lookup to (it extracts oci.pull as a
# `docker` datasource with both currentValue and currentDigest). Digest alone would be pinned
# forever with nothing to compare against — the same trap the devcontainer features hit.
oci.pull(
    name = "devcontainers_base_debian",
    digest = "sha256:025b74bb5f7ac53edd77e01aa7188c359aab100e23a2f6220bde50bbb9fd31dd",
    image = "mcr.microsoft.com/devcontainers/base",
    platforms = [
        "linux/amd64",
        "linux/arm64",
    ],
    tag = "debian",
)
use_repo(
    oci,
    "devcontainers_base_debian",
    "devcontainers_base_debian_linux_amd64",
    "devcontainers_base_debian_linux_arm64",
)