-
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
Bzlmod: a project cannot provide a macro that uses select statement #14259
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
Comments
meteorcloudy
added
type: bug
P2
We'll consider working on this in future. (Assignee optional)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
labels
Nov 11, 2021
gregestren
added
the
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
label
Nov 18, 2021
philwo
removed
the
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
label
Nov 29, 2021
@meteorcloudy Is this something that you would work on for Bazel 5.1.0? I am asking because it currently blocks |
@fmeum It would be awesome if you could help looking into this! Thanks! |
I'm happy to provide guidance! |
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Dec 19, 2021
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select's. This commit also updates the docs for Label, select and macros. Fixes bazelbuild#14259.
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Dec 19, 2021
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select's. This commit also updates the docs for Label, select and macros. Fixes bazelbuild#14259.
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Dec 19, 2021
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select. This commit also updates the docs for Label, select and macros. Fixes bazelbuild#14259.
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Dec 19, 2021
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select. This commit also updates the docs for Label, select and macros. Fixes bazelbuild#14259.
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Dec 19, 2021
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select. This commit also updates the docs for Label, select and macros. Fixes bazelbuild#14259.
@bazel-io fork 5.1 |
brentleyjones
pushed a commit
to brentleyjones/bazel
that referenced
this issue
Feb 8, 2022
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select. This commit also updates the docs for Label, select and macros. Fixes bazelbuild#14259. Closes bazelbuild#14447. PiperOrigin-RevId: 417386977 (cherry picked from commit 69f8b17)
Wyverald
pushed a commit
that referenced
this issue
Feb 9, 2022
When a macro specifies a label string as a key in a select, this label is resolved relative to the site of use rather than the .bzl file the macro is defined in. The resolution will lead to incorrect results if the repository that uses the macro has a different repo mapping, e.g. because it is created by another Bazel module. This can be solved by allowing macros to specify label instances created with the `Label` constructor instead of label strings everywhere, which previously was not possible in select. This commit also updates the docs for Label, select and macros. Fixes #14259. Closes #14447. PiperOrigin-RevId: 417386977 (cherry picked from commit 69f8b17) Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
P2
We'll consider working on this in future. (Assignee optional)
team-ExternalDeps
External dependency handling, remote repositiories, WORKSPACE file.
type: bug
For example in rules_pkg, //private:private_stamp_detect is a config setting in rules_pkg for filling the value of private_stamp_detect, which is defined in a macro
pkg_tar
.In rules_pkg, the final condition label string is calculated as:
This is because:
//private:private_stamp_detect
as the select key, because it will be relative to the main repo that uses thepkg_tar
macro.Label(//private:private_stamp_detect)
, this made sure the package path is relative to rules_pkg.select
doesn't accept label as key, then rules_pkg has to convert it back to a string.In Bzlmod, we enforces repo level strict deps via repo mapping, each repo has a repo mapping that contains all the repos it can see. In this case, if A depends on rules_pkg at version 0.5.1, then there is a mapping
@rules_pkg
(local name) ->@rules_pkg.0.5.1
(canonical name). We resolve the repo mapping when constructing a Label from a label string.This will break the above use case, because
_stamp_condition
will have to go through repo mapping twice. The first time,//private:private_stamp_detect
is resolved to@rules_pkg.0.5.1//private:private_stamp_detect
with rules_pkg's repo mapping, and the second time theselect
statement tries to resolve@rules_pkg.0.5.1//private:private_stamp_detect
with A's repo mapping but only finds out@rules_pkg.0.5.1
(local name) doesn't exist because the local repo name should be@rules_pkg
.The solution is to let
select
accept Label as the key type, therefore we can skip the second repo mapping.The text was updated successfully, but these errors were encountered: