Bzlmod: a project cannot provide a macro that uses select statement #14259
Description
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_detectas the select key, because it will be relative to the main repo that uses thepkg_tarmacro. - 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
selectdoesn'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.