bazelbuild / bazelbuild/bazel

Allow accessing package defaults from rules in the package

Closed
#25,415 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:

# Problem
Bazel Style Guide suggests for BUILD file structures like
https://bazel.build/build/style-guide#file-structure

```
1. Package description (a comment)
2. All load() statements
3. The package() function.
4. Calls to rules and macros
```

However, it is a common recurrence that we need to reference shared properties in the `package()` function and the rules.
The most common example would be `default_visibility`, where a package defines a default_visibility, and a rule within the package should be visible to the packages in `default_visibility` AND additional packages. In which case, the best option we have found is to define a shared variable like:

```
# NOTE: This violates style guide since it has to go before the package() function.
DEFAULT_VISIBILITY = [
"foo/bar:__subpackages__",
]
package(default_visibility = DEFAULT_VISIBILITY)

some_library(
name = "rule_with_default_visibility",
...
)

some_library(
name = "rule_with_extended_visibility",
...
visibility = DEFAULT_VISIBILITY + [
"some/other/package:__subpackages__",
],
)
```

# Feature Request / Proposal:
It would look nicer (and adhere to the style guide) if our build files could reference properties of the current package instead of having to define a custom variable.

e.g. `package`, `current_package` or `package_defaults` could be made available as a global reference, with which the above example could be implemented as:

```
package(default_visibility = [
"foo/bar:__subpackages__",
])

some_library(
name = "rule_with_default_visibility",
...
)

some_library(
name = "rule_with_extended_visibility",
...
# Using global reference "package_defaults"
visibility = package_defaults.visibility + [
"some/other/package:__subpackages__"
],
)
```

## Different option (implementation avoiding exposed global reference)

An additional option for approaching this which avoids the global reference, would be through some built-in macro like:

```
some_library(
name = "rule_with_extended_visibility",
...
visibility = package_default_visibility_and([
"some/other/package:__subpackages__",
]),
)
```
Which personally I find less readable.

## Additional option 2

If only addressing the visibility part, which is the main issue we have come across, similarly to "//visibility:public", a new value could be added like "//visibility:package_default", resulting in something like.

```
some_library(
name = "rule_with_extended_visibility",
...
visibility = [
"//visibility:package_default",
"some/other/package:__subpackages__",
]),
)
```
Which may in fact be the most readable and simplest option

### Which category does this issue belong to?

Loading API

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

Improved BUILD file style, avoiding duplication and unnecessary variables.

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

_No response_

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

_No response_

### 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?

https://github.com/bazelbuild/bazel/issues/25314 - Seems to mention the same issues but on a less general level

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

_No response_

Contributor guide

Open the contributing guide

Research direction

No source files, tests, or implementation entry points are named. Start by reviewing the related issue #25314 and the proposed alternatives, then determine which package-default behavior should be supported and how it should be tested. Done means a selected approach is implemented with coverage for referencing package defaults from rules.

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
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.