bazelbuild / bazelbuild/bazel

Add option to apply patches on local_path_override, preferrably automatically deduced from the registry

Open
#21,307 2 comments 1 reaction 0 assignees View on GitHub
area-Bzlmod P3 team-ExternalDeps type: feature request
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 20h
Merged PRs (30d)
72

Description

### Description of the feature request:

Could we request to add `local_path_override(patches = ...)`, and perhaps also add `patch_cmd`?

When specified, the behavior is as-if the local path is cloned, then applied patches on top of it.

### Which category does this issue belong to?

_No response_

### What underlying problem are you trying to solve with this feature?

For Android kernel builds, all dependent modules must be vendored locally. We are currently using local_path_override to point to source trees checked into external/ ([example for rules_cc](https://android.googlesource.com/platform/external/bazelbuild-rules_cc)). However, because `local_path_override` does not have a `patches` argument, we have to apply the patches manually to the source tree and check it in to AOSP Gerrit. This makes the tree look different from upstream, and cause merge conflicts when we pull from upstream.

In AOSP, we have the BCR checked in ([link](https://android.googlesource.com/platform/external/bazelbuild-bazel-central-registry/)), so we already know the list of patches to apply for each version of each module.

Here are some designs of APIs I propose:

```
# a. (my favorite solution) local_path_override() accept a single boolean. Bazel figures out the list of patches from BCR.
# If the resolved version is not 0.5.0, then the patches for the resolved version are used instead.
bazel_dep(name = "foo", version = "0.5.0")
local_path_override(
module_name = "foo",
path = "external/foo",
apply_patches_from_registry = True,
)

# b. local_path_override() accept patches.
# Cons: list of patches must be manually written.
bazel_dep(name = "foo")
local_path_override(
module_name = "foo",
path = "external/foo",
patches = ["external/bazelbuild-bazel-central-registry/modules/foo/0.5.0/patches/a.patch", ...]
)

# c. Like a. but a separate macro
bazel_dep(name = "foo", version = "0.5.0")
source_override(
module_name = "foo",
path = "external/foo",
)
```

---

As a side note, these patches are usually in place to add or modify MODULE.bazel files, for example:
- Modules that actually check in the MODULE.bazel file to their source tree
e.g. rules_cc: [in the source tree](https://github.com/bazelbuild/rules_cc/blob/0.0.9/MODULE.bazel), [in the registry](https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/rules_cc/0.0.9/MODULE.bazel), and [a patch](https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/rules_cc/0.0.9/patches/module_dot_bazel_version.patch) that resolves the discrepancy.
- Modules that don't have a MODULE.bazel file in their source tree.
e.g. liburing: [in the registry](https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/liburing/2.5/MODULE.bazel), and [a patch](https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/liburing/2.5/patches/module_dot_bazel.patch) that adds it to the source tree

This feature request aims to provide a more generic solution to any patches, regardless of whether they are related to MODULE.bazel.

### Which operating system are you running Bazel on?

Linux

### What is the output of `bazel info release`?

release 7.0.1

### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.

N/A

### What's the output of `git remote get-url origin; git rev-parse HEAD` ?

```text
N/A
```

### Have you found anything relevant by searching the web?

This is also requested in https://stackoverflow.com/q/77132444, in a way.

### Any other information, logs, or outputs that you want to share?

_No response_

Contributor guide

Open the contributing guide

Research direction

Start with the local_path_override() module API and the BCR patch metadata described in the issue. Compare the proposed automatic registry lookup, explicit patches argument, and separate source_override() designs, then determine which behavior and API are accepted. Done means local source trees can use the relevant registry patches without manually modifying vendored sources.

Written by the indexing model from the issue text.

Assessment

Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.