Allow accessing package defaults from rules in the package
- 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
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