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

Bzlmod: a project cannot provide a macro that uses select statement #14259

Closed
meteorcloudy opened this issue Nov 11, 2021 · 4 comments
Closed
Assignees
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
Copy link
Member

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:

_stamp_condition = str(Label("//private:private_stamp_detect"))

This is because:

  • we cannot just use //private:private_stamp_detect as the select key, because it will be relative to the main repo that uses the pkg_tar macro.
  • then rules_pkg has to convert it to a label with a specific repo name via Label(//private:private_stamp_detect), this made sure the package path is relative to rules_pkg.
  • But 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 the select 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.

@meteorcloudy 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 gregestren added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 18, 2021
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
@fmeum
Copy link
Collaborator

fmeum commented Dec 15, 2021

@meteorcloudy Is this something that you would work on for Bazel 5.1.0? I am asking because it currently blocks rules_fuzzing from becoming a module and if you are busy with other things, I could look into working on it.

@meteorcloudy
Copy link
Member Author

@fmeum It would be awesome if you could help looking into this! Thanks!

@Wyverald
Copy link
Member

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.
@Wyverald
Copy link
Member

Wyverald commented Feb 7, 2022

@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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants