Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the REPO.bazel proposal #18077

Closed
2 tasks done
Wyverald opened this issue Apr 13, 2023 · 0 comments
Closed
2 tasks done

Implement the REPO.bazel proposal #18077

Wyverald opened this issue Apr 13, 2023 · 0 comments
Assignees
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@Wyverald
Copy link
Member

Wyverald commented Apr 13, 2023

https://docs.google.com/document/d/1rS-B3d_sfZFY2AcSwIq2ibQc7X1lgeycddLJqjYKgOA/edit

  • Support REPO.bazel as a workspace boundary marker
  • Add support for the repo() function / evaluating REPO.bazel files
@Wyverald Wyverald added type: feature request P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. area-Bzlmod Bzlmod-specific PRs, issues, and feature requests labels Apr 13, 2023
@Wyverald Wyverald self-assigned this Apr 13, 2023
copybara-service bot pushed a commit that referenced this issue Apr 13, 2023
Work towards #18077

RELNOTES: The REPO.bazel and MODULE.bazel files are now also considered workspace boundary markers.
PiperOrigin-RevId: 523979135
Change-Id: I0cbc9964742a0e5efa8afac8b8dfb84c6235a2f0
copybara-service bot pushed a commit that referenced this issue Apr 17, 2023
- Added a FeatureSet type to represent a set of "on" features and a set of "off" features
- This type supports merging different feature sets with different granularity (so package-level defaults get overridden by rule-level features, for example)
  - This'll allow repo-level defaults to be overridden by package-level defaults in the future
- Global (flag-level) features are handled specially (with `mergeWithGlobalFeatures`)
- This gets rid of the frankly ridiculously complex logic in RuleContext; no behavior change is introduced.

Work towards #18077

PiperOrigin-RevId: 524832614
Change-Id: Ic37b80771f1627573485e564d39944e68c6a6524
fweikert pushed a commit to fweikert/bazel that referenced this issue May 25, 2023
Work towards bazelbuild#18077

RELNOTES: The REPO.bazel and MODULE.bazel files are now also considered workspace boundary markers.
PiperOrigin-RevId: 523979135
Change-Id: I0cbc9964742a0e5efa8afac8b8dfb84c6235a2f0
fweikert pushed a commit to fweikert/bazel that referenced this issue May 25, 2023
- Added a FeatureSet type to represent a set of "on" features and a set of "off" features
- This type supports merging different feature sets with different granularity (so package-level defaults get overridden by rule-level features, for example)
  - This'll allow repo-level defaults to be overridden by package-level defaults in the future
- Global (flag-level) features are handled specially (with `mergeWithGlobalFeatures`)
- This gets rid of the frankly ridiculously complex logic in RuleContext; no behavior change is introduced.

Work towards bazelbuild#18077

PiperOrigin-RevId: 524832614
Change-Id: Ic37b80771f1627573485e564d39944e68c6a6524
copybara-service bot pushed a commit that referenced this issue Jun 12, 2023
- Created a PackageArgs class that stores the values passed to the attrs of the `package()` function, so that they can be applied to a package builder in one go
  - These attr values used to be applied as soon as each attr is processed (i.e. evaluated). We can't do that anymore for repo(), since at the time of REPO.bazel evaluation, the package hasn't started being built yet.
  - Instead of storing the individual fields, Package now just holds on to a PackageArgs object.
  - In a follow-up CL, we store all the repo() values in a PackageArgs class, and apply those before the package() ones.
- Also removed `Package#isDefaultVisibilitySet` as nobody calls it anymore.

Work towards #18077

PiperOrigin-RevId: 539728608
Change-Id: Ie4a081fa0e52e833ac2a6be50033f95728da3a9b
traversaro pushed a commit to traversaro/bazel that referenced this issue Jun 24, 2023
- Created a PackageArgs class that stores the values passed to the attrs of the `package()` function, so that they can be applied to a package builder in one go
  - These attr values used to be applied as soon as each attr is processed (i.e. evaluated). We can't do that anymore for repo(), since at the time of REPO.bazel evaluation, the package hasn't started being built yet.
  - Instead of storing the individual fields, Package now just holds on to a PackageArgs object.
  - In a follow-up CL, we store all the repo() values in a PackageArgs class, and apply those before the package() ones.
- Also removed `Package#isDefaultVisibilitySet` as nobody calls it anymore.

Work towards bazelbuild#18077

PiperOrigin-RevId: 539728608
Change-Id: Ie4a081fa0e52e833ac2a6be50033f95728da3a9b
meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Jun 27, 2023
Work towards bazelbuild#18077

RELNOTES: The REPO.bazel and MODULE.bazel files are now also considered workspace boundary markers.
PiperOrigin-RevId: 523979135
Change-Id: I0cbc9964742a0e5efa8afac8b8dfb84c6235a2f0
Wyverald added a commit that referenced this issue Jun 27, 2023
Work towards #18077

RELNOTES: The REPO.bazel and MODULE.bazel files are now also considered workspace boundary markers.
PiperOrigin-RevId: 523979135
Change-Id: I0cbc9964742a0e5efa8afac8b8dfb84c6235a2f0

Co-authored-by: Googler <[email protected]>
@Wyverald Wyverald added this to Bzlmod Jul 12, 2023
@Wyverald Wyverald moved this to Todo in Bzlmod Jul 12, 2023
@Wyverald Wyverald added this to the 7.0.0 branch cut milestone Jul 13, 2023
@github-project-automation github-project-automation bot moved this from Todo to Done in Bzlmod Jul 26, 2023
copybara-service bot pushed a commit to bazelbuild/intellij that referenced this issue Jul 26, 2023
- REPO.bazel is a new file at the root of repos that can only contain a `repo()` call with a bunch of package default arguments (similar to `package()`)
- A new SkyFunction, RepoFileFunction, evaluates a REPO.bazel file and returns the `PackageArgs` object containing those arguments
- PackageFunction for packages in repo `@foo` now depends on RepoFileFunction for `@foo`

Fixes bazelbuild/bazel#18077

PiperOrigin-RevId: 551313372
mai93 pushed a commit to bazelbuild/intellij that referenced this issue Jul 31, 2023
- REPO.bazel is a new file at the root of repos that can only contain a `repo()` call with a bunch of package default arguments (similar to `package()`)
- A new SkyFunction, RepoFileFunction, evaluates a REPO.bazel file and returns the `PackageArgs` object containing those arguments
- PackageFunction for packages in repo `@foo` now depends on RepoFileFunction for `@foo`

Fixes bazelbuild/bazel#18077

(cherry picked from commit 45e1b5c)
copybara-service bot pushed a commit to bazelbuild/intellij that referenced this issue Aug 3, 2023
*** Reason for rollback ***

Performance regression, b/294105788

*** Original change description ***

Implement REPO.bazel

- REPO.bazel is a new file at the root of repos that can only contain a `repo()` call with a bunch of package default arguments (similar to `package()`)
- A new SkyFunction, RepoFileFunction, evaluates a REPO.bazel file and returns the `PackageArgs` object containing those arguments
- PackageFunction for packages in repo `@foo` now depends on RepoFileFunction for `@foo`

Fixes bazelbuild/bazel#18077

PiperOrigin-RevId: 553500673
copybara-service bot pushed a commit that referenced this issue Aug 3, 2023
*** Reason for rollback ***

Performance regression, b/294105788

*** Original change description ***

Implement REPO.bazel

- REPO.bazel is a new file at the root of repos that can only contain a `repo()` call with a bunch of package default arguments (similar to `package()`)
- A new SkyFunction, RepoFileFunction, evaluates a REPO.bazel file and returns the `PackageArgs` object containing those arguments
- PackageFunction for packages in repo `@foo` now depends on RepoFileFunction for `@foo`

Fixes #18077

PiperOrigin-RevId: 553500673
Change-Id: I866e73262ab75635c8927f8c77eb5412c01e16a9
fweikert pushed a commit that referenced this issue Aug 9, 2023
*** Reason for rollback ***

Performance regression, b/294105788

*** Original change description ***

Implement REPO.bazel

- REPO.bazel is a new file at the root of repos that can only contain a `repo()` call with a bunch of package default arguments (similar to `package()`)
- A new SkyFunction, RepoFileFunction, evaluates a REPO.bazel file and returns the `PackageArgs` object containing those arguments
- PackageFunction for packages in repo `@foo` now depends on RepoFileFunction for `@foo`

Fixes #18077

PiperOrigin-RevId: 553500673
Change-Id: I866e73262ab75635c8927f8c77eb5412c01e16a9
copybara-service bot pushed a commit to bazelbuild/intellij that referenced this issue Aug 11, 2023
*** Reason for rollback ***

Roll forward with changes to allow us to disable REPO.bazel in Blaze while keeping the new feature in Bazel.

Fixes bazelbuild/bazel#18077

PiperOrigin-RevId: 556025128
copybara-service bot pushed a commit that referenced this issue Aug 11, 2023
*** Reason for rollback ***

Roll forward with changes to allow us to disable REPO.bazel in Blaze while keeping the new feature in Bazel.

Fixes #18077

PiperOrigin-RevId: 556025128
Change-Id: Ic31f3d47b14d4966eead3c00c810bb04da2e051e
mai93 pushed a commit to bazelbuild/intellij that referenced this issue Aug 14, 2023
*** Reason for rollback ***

Performance regression, b/294105788

*** Original change description ***

Implement REPO.bazel

- REPO.bazel is a new file at the root of repos that can only contain a `repo()` call with a bunch of package default arguments (similar to `package()`)
- A new SkyFunction, RepoFileFunction, evaluates a REPO.bazel file and returns the `PackageArgs` object containing those arguments
- PackageFunction for packages in repo `@foo` now depends on RepoFileFunction for `@foo`

Fixes bazelbuild/bazel#18077

(cherry picked from commit e956466)
mai93 pushed a commit to bazelbuild/intellij that referenced this issue Aug 14, 2023
*** Reason for rollback ***

Roll forward with changes to allow us to disable REPO.bazel in Blaze while keeping the new feature in Bazel.

Fixes bazelbuild/bazel#18077

(cherry picked from commit ec20e61)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
Archived in project
Development

No branches or pull requests

1 participant