bazelbuild / bazelbuild/bazel

Make it possible to extend default_visibility for targets in a macro instead of override it

Closed
#25,314 0 comments 0 reactions 0 assignees View on GitHub
team-Loading-API type: feature request untriaged
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 20h
Merged PRs (30d)
72

Description

### Description of the feature request:

Today, if you want targets within a macro to always be visible to certain other targets, you can't also inherit default visibility.

### Which category does this issue belong to?

Loading API

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

E.g. consider a macro like
```
def foo(name, visibility = None, **kw):
_foo(name=name, visibility=visibility, **kw)
```

now suppose I want the targets created by foo() to always be visible to `"//bar:__subpackages__"` - regardless of default_visibility. I can write
```
def foo(name, visibility = None, **kw):
_foo(name=name, visibility=(visibility if visibility else []) + ["//bar:__subpackages__"], **kw)
```

but this means that the following:
```
package(default_visibility = ["//baz:__pkg__"])
load(...)

foo(name="my_target")
```

`:my_target` won't be visible to `//baz:__pkg__` anymore, as the added visibility means we can't pass visibility=None and the default_visibility will then be ignored.

Today this has to be manually handled by BUILD file authors or by BUILD file generators.

If bazel included a builtin function that could return the default visibility, e.g. `native.package_default_visibility()`, the macro could call that and use that:
```
def foo(name, visibility = None, **kw):
_foo(name=name, visibility=(visibility if visibility else native.package_default_visibility()) + ["//bar:__subpackages__"], **kw)
```

which would get us the best of both worlds - macros could opt in to mutate visibility while also honoring default_visibility, without pushing the problem onto BUILD file authors or generators.

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

linux

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

release 6.5.0-b940786cac09f826f5b96eaba2ff36784ad4869d

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

_No response_

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

```text

```

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

_No response_

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

_No response_

Contributor guide

Open the contributing guide

Research direction

Start by tracing Bazel's Loading API handling of package(default_visibility), macro-provided visibility, and the proposed native.package_default_visibility() behavior. Use the examples in the issue to define expected inheritance and extension cases, then add coverage showing that explicit visibility can extend the package default without replacing it.

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
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.