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.

Sign up for GitHub

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

Jump to bottom

Canonical label literals #15593

Closed
Wyverald opened this issue May 30, 2022 · 1 comment
Closed

Canonical label literals #15593

Wyverald opened this issue May 30, 2022 · 1 comment
Assignees
@Wyverald
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

See https://docs.google.com/document/d/1N81qfCa8oskCk5LqTW-LNthy6EBrDot7bdUsjz6JFC4/edit#

In short, the new label syntax @@repo_name//pkg:target will be used to represent labels that have been passed through repo mapping. This feature will be gated behind --enable_bzlmod for the time being.
@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 May 30, 2022
@Wyverald Wyverald self-assigned this May 30, 2022
This was referenced May 30, 2022
Closed
Closed
copybara-service bot pushed a commit that referenced this issue May 30, 2022
@Wyverald @copybara-github
Get rid of the '@' in RepositoryName
3c30fbc 
This CL is purely an internal refactor with no visible behavior changes.

In preparation for #15593

PiperOrigin-RevId: 451879164
Change-Id: I3642455cc324891f23ed58f4c1187ebb9ccaba78
fmeum added a commit to fmeum/rules_go that referenced this issue Jun 8, 2022
@fmeum
Replace Label(...).workspace_name with explicit repo name
7937ab5 
With the repository mappings used by bzlmod, the
Label(...).workspace_name construct always returns the canonical,
post-repo mapping repo name, which can't be used to construct a valid
label. Until bazelbuild/bazel#15593 has been
fixed, we have to hardcode the non-canonical repo name here.
fmeum added a commit to fmeum/rules_go that referenced this issue Jun 8, 2022
@fmeum
Replace Label(...).workspace_name with explicit repo name
7fb2bff 
With the repository mappings used by bzlmod, the
Label(...).workspace_name construct always returns the canonical,
post-repo mapping repo name, which can't be used to construct a valid
label. Until bazelbuild/bazel#15593 has been
fixed, we have to hardcode the non-canonical repo name here.
@fmeum fmeum mentioned this issue Jun 9, 2022
Merged
copybara-service bot pushed a commit that referenced this issue Jun 10, 2022
@Wyverald @copybara-github
'@'-prefixed canonical repo names for Bzlmod repos
de37930 
See https://docs.google.com/document/d/1N81qfCa8oskCk5LqTW-LNthy6EBrDot7bdUsjz6JFC4/edit#heading=h.z37pyziy8h33

* RepositoryName syntax is relaxed to allow an extra '@' in the beginning, signifying that the RepositoryName should bypass RepositoryMapping
* All repos generated by Bzlmod will have an extra '@' prefixed to their names (except for well-known modules)
* TODO: strip the '@' when generating paths under $outputBase/external or $execRoot/external

Work towards #15593.

RELNOTES: When Bzlmod is enabled, all Bzlmod-generated repos will have an extra '@' prepended to their names. This effectively enables the canonical label literal syntax for Bzlmod-generated repos (`@@canonicalRepoName//pkg:target`; see https://docs.google.com/document/d/1N81qfCa8oskCk5LqTW-LNthy6EBrDot7bdUsjz6JFC4/edit?usp=sharing).
PiperOrigin-RevId: 454156392
Change-Id: I2fb08495f066cfd15cc344534925f674a63764f6
@Wyverald
Copy link
Member Author

This is enabled for Bzlmod repos. For non-Bzlmod repos, we'd likely need to wait until Bazel 7 at the earliest. Closing for now.

fmeum added a commit to bazel-contrib/rules_go that referenced this issue Jul 1, 2022
@fmeum
Basic bzlmod setup (#3047)
e80bb2c 
* Replace Label(...).workspace_name with explicit repo name

With the repository mappings used by bzlmod, the
Label(...).workspace_name construct always returns the canonical,
post-repo mapping repo name, which can't be used to construct a valid
label. Until bazelbuild/bazel#15593 has been
fixed, we have to hardcode the non-canonical repo name here.

* Remove remaining repo-absolute labels in load statements

* Refactor repository macros for bzlmod

The existing repository macros can be reused for the module setup
with only very few fully backwards compatible changes:

* The macros wrapping the Go SDK repository rules should make toolchain
  registration optional. With bzlmod, toolchains are registered with the
  toolchains_to_register attribute of the module function instead.
* The repository macro should not use _maybe with bzlmod. Instead, repos
  loaded by module extensions are given globally unique internal names
  automatically.

* Add basic bzlmod setup

This commit adds a MODULE.bazel that makes rules_go usable as a bzlmod
module for basic use cases.

The new module definition is verified by a test module that will be used
in the presubmit tests of the Bazel Central Registry (BCR).

The following features require more thought and/or work and are not yet
supported:
* SDK rules other than go_host_sdk and go_download_sdk.
* non-no-op nogo
* go_proto_library
@meteorcloudy meteorcloudy mentioned this issue Sep 5, 2022
Merged
@alexeagle alexeagle mentioned this issue Oct 21, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Wyverald Wyverald

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
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Wyverald