-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Omit unique module versions from canonical repo names #21035
Conversation
35962c8
to
6c55580
Compare
6c55580
to
3264860
Compare
@Wyverald @meteorcloudy Could you already take a look at the implementation? If you agree with the new naming scheme and the overall implementation, I would go ahead and fix all the tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall LGTM
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/BazelDepGraphFunction.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/BazelDepGraphFunction.java
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleKey.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleFileFunction.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleKey.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/ModuleKey.java
Outdated
Show resolved
Hide resolved
4398798
to
c077db3
Compare
5cda597
to
f7379b1
Compare
src/main/java/com/google/devtools/build/lib/bazel/bzlmod/BazelDepGraphFunction.java
Show resolved
Hide resolved
@Wyverald @meteorcloudy Tests are passing now, I had to update the canonical name of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! ❤️
67bdda8
to
2bddce6
Compare
2bddce6
to
8cbb5f2
Compare
@meteorcloudy I addressed your comment and also added RELNOTES to the PR description. |
@bazel-io fork 7.1.0 |
The canonical repository name of a module `rules_foo` is now `rules_foo~` instead of e.g. `rules_foo~1.2.3` if there is only a single version of the module in the entire dep graph. This also applies to overrides, which previously used the canonical repository name `rules_foo~override`. This improves cacheability of actions across module version changes and also prevents the output base from filling up with outdated module and extension repositories. See the long comment in `ModuleKey#getCanonicalRepoName` for a detailed explanation of why this particular scheme was chosen. The change includes a bump of the lockfile version as the canonical repo names of label attributes in extension usages are affected. RELNOTES: The scheme for generating canonical repository names has changed to improve cacheability of actions across dependency version updates. Note that canonical names are not considered to be public API and can change at any time. See https://bazel.build/external/module#repository_names_and_strict_deps for advice on how to avoid hardcoding canonical repository names. Fixes #20997 Closes #21035. PiperOrigin-RevId: 605730371 Change-Id: Ica1be1ba5493d3636248a79a6549a0927021bef9
The canonical repository name of a module `rules_foo` is now `rules_foo~` instead of e.g. `rules_foo~1.2.3` if there is only a single version of the module in the entire dep graph. This also applies to overrides, which previously used the canonical repository name `rules_foo~override`. This improves cacheability of actions across module version changes and also prevents the output base from filling up with outdated module and extension repositories. See the long comment in `ModuleKey#getCanonicalRepoName` for a detailed explanation of why this particular scheme was chosen. The change includes a bump of the lockfile version as the canonical repo names of label attributes in extension usages are affected. RELNOTES: The scheme for generating canonical repository names has changed to improve cacheability of actions across dependency version updates. Note that canonical names are not considered to be public API and can change at any time. See https://bazel.build/external/module#repository_names_and_strict_deps for advice on how to avoid hardcoding canonical repository names. Fixes #20997 Closes #21035. PiperOrigin-RevId: 605730371 Change-Id: Ica1be1ba5493d3636248a79a6549a0927021bef9
The canonical repository name of a module `rules_foo` is now `rules_foo~` instead of e.g. `rules_foo~1.2.3` if there is only a single version of the module in the entire dep graph. This also applies to overrides, which previously used the canonical repository name `rules_foo~override`. This improves cacheability of actions across module version changes and also prevents the output base from filling up with outdated module and extension repositories. See the long comment in `ModuleKey#getCanonicalRepoName` for a detailed explanation of why this particular scheme was chosen. The change includes a bump of the lockfile version as the canonical repo names of label attributes in extension usages are affected. RELNOTES: The scheme for generating canonical repository names has changed to improve cacheability of actions across dependency version updates. Note that canonical names are not considered to be public API and can change at any time. See https://bazel.build/external/module#repository_names_and_strict_deps for advice on how to avoid hardcoding canonical repository names. Fixes #20997 Closes #21035. PiperOrigin-RevId: 605730371 Change-Id: Ica1be1ba5493d3636248a79a6549a0927021bef9 Co-authored-by: Fabian Meumertzheim <[email protected]>
The changes in this PR have been included in Bazel 7.1.0 RC1. Please test out the release candidate and report any issues as soon as possible. If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=last_rc. |
The canonical repository name of a module
rules_foo
is nowrules_foo~
instead of e.g.rules_foo~1.2.3
if there is only a single version of the module in the entire dep graph. This also applies to overrides, which previously used the canonical repository namerules_foo~override
.This improves cacheability of actions across module version changes and also prevents the output base from filling up with outdated module and extension repositories. See the long comment in
ModuleKey#getCanonicalRepoName
for a detailed explanation of why this particular scheme was chosen.The change includes a bump of the lockfile version as the canonical repo names of label attributes in extension usages are affected.
RELNOTES: The scheme for generating canonical repository names has changed to improve cacheability of actions across dependency version updates. Note that canonical names are not considered to be public API and can change at any time. See https://bazel.build/external/module#repository_names_and_strict_deps for advice on how to avoid hardcoding canonical repository names.
Fixes #20997