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

incompatible_remap_main_repo: treat @main_repo//, @//, and // labels as equivalent. #7130

Closed
dkelmer opened this issue Jan 15, 2019 · 25 comments
Closed

incompatible_remap_main_repo: treat @main_repo//, @//, and // labels as equivalent. #7130

dkelmer opened this issue Jan 15, 2019 · 25 comments
Assignees
@aehlig
Labels
incompatible-change Incompatible/breaking change P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.

Comments

@dkelmer
Copy link
Contributor

dkelmer commented Jan 15, 2019

All PRs related to this change have been submitted and the behavior will not continue to evolve so this feature should be promoted to non-experimental state
@dkelmer dkelmer changed the title Promote --experimental_remap_main_repo to not be experimental incompatible_remap_main_repo Jan 16, 2019
@dkelmer dkelmer added the incompatible-change Incompatible/breaking change label Jan 16, 2019
@dkelmer
Copy link
Contributor Author

dkelmer commented Jan 16, 2019

This flag changes the evaluation of labels where within a repository called "foo", the labels:
@foo//some/path:lib
//some/path:lib
will be treated as the same label. Right now they are treated as two different labels.

This incompatible change is fixing a bug but it is possible that people are relying on the broken behavior in unexpected ways. Chances are no one will need to do anything, but if you encounter issues, please respond on this thread.

bazel-io pushed a commit that referenced this issue Jan 17, 2019
@dkelmer
Create --incompatible_remap_main_repo flag.
ed87463 
This flag fixes a bug in bazel where within a repository called "foo", the labels @foo//some/path:bar.bzl and //some/path:bar.bzl were treated as different labels. It is unlikely that this flag will affect any projects but it is technically a breaking change and so it is guarded behind a flag.

Towards #7130

RELNOTES: None
PiperOrigin-RevId: 229813128
@clintharrison clintharrison mentioned this issue Jan 18, 2019
Closed
weixiao-huang pushed a commit to weixiao-huang/bazel that referenced this issue Jan 31, 2019
@dkelmer @weixiao-huang
Create --incompatible_remap_main_repo flag.
19b0bc6 
This flag fixes a bug in bazel where within a repository called "foo", the labels @foo//some/path:bar.bzl and //some/path:bar.bzl were treated as different labels. It is unlikely that this flag will affect any projects but it is technically a breaking change and so it is guarded behind a flag.

Towards bazelbuild#7130

RELNOTES: None
PiperOrigin-RevId: 229813128
@jin jin added the team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. label Feb 19, 2019
bazel-io pushed a commit that referenced this issue Feb 27, 2019
@dkelmer @copybara-github
Set default value of --incompatible_remap_main_repo to true.
dfd48fc 
Related to #7130

RELNOTES: Set default value of --incompatible_remap_main_repo to true.
PiperOrigin-RevId: 235945449
bazel-io pushed a commit that referenced this issue Feb 28, 2019
@meteorcloudy @copybara-github
Automated rollback of commit dfd48fc.
70981cd 
*** Reason for rollback ***

Broke Bazel CI: #7577

*** Original change description ***

Set default value of --incompatible_remap_main_repo to true.

Related to #7130

RELNOTES: Set default value of --incompatible_remap_main_repo to true.
PiperOrigin-RevId: 236084411
@katre
Copy link
Member

katre commented Mar 1, 2019

This issue was tagged as "breaking-change-0.24" but does not appear ready to be flipped in the 0.24.0 release. If this is incorrect please comment on that issue and discuss with me.

@dkelmer
Copy link
Contributor Author

dkelmer commented Mar 4, 2019

@katre I was fully intending to flip it this time but I accidentally set a reminder to flip the flag right before the 0.24 cut as opposed to right after the 0.23 cut. Surprise surprise, there were breakages and I now missed the deadline :(

So I'm now aiming for 0.25. Is there something I should update?

@katre
Copy link
Member

katre commented Mar 4, 2019

No, the labels are accurate now.

@dkelmer
Copy link
Contributor Author

dkelmer commented Mar 4, 2019

Thanks!

@deeglaze
Copy link
Contributor

What is y'all's recommendation for a crosstool that depends on project X's sources to build project X, project Y (external dependency of X), and project Z (depends on X as an external dependency)?

I haven't found any way to make a single crosstool definition work for all three cases when --incompatible_remap_main_repo=true.

We get all 3 cases to work when the flag is false and our crosstool always references project X path via external/project_x_workspace/path
https://github.com/google/asylo/blob/master/asylo/distrib/sgx_x86_64/CROSSTOOL.tpl#L49

If I disregard project Z, then dropping external/project_x_workspace/ works fine. If I add both path and external/project_x_workspace/path to my crosstool, then #include_next breaks within project X and project Y, since both paths exist, and the first will go to the second instead of the system header I want.

I've since migrated the referenced CROSSTOOL to the skylark representation, and thought that I could possibly detect whether the crosstool is used by an external dependency or an internal dependency and add the appropriate paths, but this is both nasty and I don't know if it's possible.

@deeglaze
Copy link
Contributor

Would it be possible for Bazel to create a symlink external/main_repo_name to the main repo's source directory so that there is a canonical path to the workspace's sources both inside and outside the workspace? If the labels are the same, I think the path structures should resolve to the same place, rather than one no longer existing.

@dslomov dslomov mentioned this issue Mar 21, 2019
Closed
@dslomov dslomov added the P1 I'll work on this now. (Assignee required) label Mar 22, 2019
@hlopko
Copy link
Member

hlopko commented Mar 29, 2019

@deeglaze Would it be possible to create a tiny repro repository that demonstrates all your requirements that I can play with? Right now I don't see what changes with --incompatible_remap_main_repo and my naive repro attempt is not successful.

With Crosstool in Starlark the next logical step would be to accept artifacts for tool paths. I'd like to play with it more and your input would be very helpful. Related discussion is happening over at #7746, feel free to join.

bazel-io pushed a commit that referenced this issue Sep 20, 2019
@aehlig @copybara-github
Apply repository-mapping also to target patterns
94e6cf6 
Target patterns are to be read in the name space of the main
repository. This namespace, however, can also contain a mapping
of repository names, in particular that of the main repository
(#7130, #3155).

While there, also make an error message more informative. (This
message change is related as the modified evaluation order causes
another error to be found first in a test example.)

Change-Id: I022240e5c201d33e31f2a818f74a91af3b6f7b3d
PiperOrigin-RevId: 270240453
bazel-io pushed a commit that referenced this issue Sep 25, 2019
@aehlig @copybara-github
Also for default attributes correctly convert strings to labels
f371448 
...by taking the applicable repository mapping into account, instead
of simply assuming it is empty.

Related to #7130, #3115.

Change-Id: I7f3274b7e238ec0a9ad00643b738fbb12b84a872
PiperOrigin-RevId: 271133642
@laurentlb
Copy link
Contributor

@aehlig Did you flip the flag for Bazel 2.0? If so, please close this issue.

@aehlig
Copy link
Contributor

aehlig commented Nov 18, 2019

@aehlig Did you flip the flag for Bazel 2.0? If so, please close this issue.

The flag was flipped in 81b57d6, but there are some discussions in #10246 about undoing the flag flip. Stll, at the moment, the flag is flipped.

@aehlig aehlig closed this as completed Nov 18, 2019
This was referenced Nov 19, 2019
Closed
Closed
@jayconrod jayconrod mentioned this issue Dec 2, 2019
Open
bazel-io pushed a commit that referenced this issue Dec 19, 2019
@aehlig
Release 2.0.0 (2019-12-19)
59e3600 
Baseline: 807ed23

Cherry picks:

   + db0e32c:
     build.sh: Fix bug in build script for RC release
   + 85e84f7:
     Set --incompatible_prohibit_aapt1 default to true.
   + 84eae2f:
     Let shellzelisk fallback to bazel-real if it's the requested
     version.
   + d5ae460:
     Fix a typo in bazel.sh

Incompatible changes:

  - --incompatible_remap_main_repo is enabled by default. Therefore,
    both ways of addressing the main repository, by its name and by
    '@' are now considered referring to the same repository.
    see #7130
  - --incompatible_disallow_dict_lookup_unhashable_keys is enabled by
    default #9184
  - --incompatible_remove_native_maven_jar is now enabled by default
    and the flag removed. See #6799
  - --incompatible_prohibit_aapt1 is enabled by default.
    See #10000

Important changes:

  - --incompatible_proto_output_v2: proto v2 for aquery proto output
    formats, which reduces the output size compared to v1. Note that
    the messages' ids in v2 are in uint64 instead of string like in
    v1.
  - Adds --incompatible_remove_enabled_toolchain_types.
  - Package loading now consistently fails if package loading had a
    glob evaluation that encountered a symlink cycle or symlink
    infinite expansion. Previously, such package loading with such
    glob evaluations would fail only in some cases.
  - The --disk_cache flag can now also be used together
    with the gRPC remote cache.
  - An action's discover inputs runtime metrics is now categorized as
    parse time on the CriticalPathComponent.
  - Make the formatting example more like to the written text by
    adding an initial description.
  - An action's discover inputs runtime metrics is now categorized as
    parse time on the CriticalPathComponent.
  - Bazel's Debian package and the binary installer now include an
    improved wrapper that understands `<WORKSPACE>/.bazelversion`
    files and the `$USE_BAZEL_VERSION` environment variable. This is
    similar to what Bazelisk offers
    (https://github.com/bazelbuild/bazelisk#how-does-bazelisk-know-whi
    ch-bazel-version-to-run-and-where-to-get-it-from), except that it
    works offline and integrates with apt-get.
  - We are planning to deprecate the runfiles manifest files, which
    aren't safe in the presence of whitespace, and also unnecessarily
    require local CPU when remote execution is used. This release
    adds --experimental_skip_runfiles_manifests to disable the
    generation of the input manifests (rule.manifest files) in most
    cases. Note that this flag has no effect on Windows by default or
    if --experimental_enable_runfiles is explicitly set to false.

This release contains contributions from many people at Google, as well as aldersondrive, Benjamin Peterson, Bor Kae Hwang, David Ostrovsky, Jakob Buchgraber, Jin, John Millikin, Keith Smiley, Lauri Peltonen, nikola-sh, Peter Mounce, Tony Hsu.
meteorcloudy pushed a commit to meteorcloudy/bazel that referenced this issue Jan 10, 2020
@aehlig
Release 2.0.0 (2019-12-19)
50514fc 
Baseline: 807ed23

Cherry picks:

   + db0e32c:
     build.sh: Fix bug in build script for RC release
   + 85e84f7:
     Set --incompatible_prohibit_aapt1 default to true.
   + 84eae2f:
     Let shellzelisk fallback to bazel-real if it's the requested
     version.
   + d5ae460:
     Fix a typo in bazel.sh

Incompatible changes:

  - --incompatible_remap_main_repo is enabled by default. Therefore,
    both ways of addressing the main repository, by its name and by
    '@' are now considered referring to the same repository.
    see bazelbuild#7130
  - --incompatible_disallow_dict_lookup_unhashable_keys is enabled by
    default bazelbuild#9184
  - --incompatible_remove_native_maven_jar is now enabled by default
    and the flag removed. See bazelbuild#6799
  - --incompatible_prohibit_aapt1 is enabled by default.
    See bazelbuild#10000

Important changes:

  - --incompatible_proto_output_v2: proto v2 for aquery proto output
    formats, which reduces the output size compared to v1. Note that
    the messages' ids in v2 are in uint64 instead of string like in
    v1.
  - Adds --incompatible_remove_enabled_toolchain_types.
  - Package loading now consistently fails if package loading had a
    glob evaluation that encountered a symlink cycle or symlink
    infinite expansion. Previously, such package loading with such
    glob evaluations would fail only in some cases.
  - The --disk_cache flag can now also be used together
    with the gRPC remote cache.
  - An action's discover inputs runtime metrics is now categorized as
    parse time on the CriticalPathComponent.
  - Make the formatting example more like to the written text by
    adding an initial description.
  - An action's discover inputs runtime metrics is now categorized as
    parse time on the CriticalPathComponent.
  - Bazel's Debian package and the binary installer now include an
    improved wrapper that understands `<WORKSPACE>/.bazelversion`
    files and the `$USE_BAZEL_VERSION` environment variable. This is
    similar to what Bazelisk offers
    (https://github.com/bazelbuild/bazelisk#how-does-bazelisk-know-whi
    ch-bazel-version-to-run-and-where-to-get-it-from), except that it
    works offline and integrates with apt-get.
  - We are planning to deprecate the runfiles manifest files, which
    aren't safe in the presence of whitespace, and also unnecessarily
    require local CPU when remote execution is used. This release
    adds --experimental_skip_runfiles_manifests to disable the
    generation of the input manifests (rule.manifest files) in most
    cases. Note that this flag has no effect on Windows by default or
    if --experimental_enable_runfiles is explicitly set to false.

This release contains contributions from many people at Google, as well as aldersondrive, Benjamin Peterson, Bor Kae Hwang, David Ostrovsky, Jakob Buchgraber, Jin, John Millikin, Keith Smiley, Lauri Peltonen, nikola-sh, Peter Mounce, Tony Hsu.
bazel-io pushed a commit that referenced this issue Jan 15, 2020
@laurentlb @copybara-github
Delete the flag --incompatible_remap_main_repo
8cb336a 
#7130

RELNOTES: The flag --incompatible_remap_main_repo is removed.
PiperOrigin-RevId: 289822459
laurentlb added a commit to laurentlb/bazel-federation that referenced this issue Jan 15, 2020
@laurentlb
Remove flag --incompatible_remap_main_repo
80f1f63 
It's on by default since Bazel 2.0, and the flag is now going away.

bazelbuild/bazel#7130
@laurentlb laurentlb mentioned this issue Jan 15, 2020
Merged
laurentlb added a commit to laurentlb/bazel-skylib that referenced this issue Jan 15, 2020
@laurentlb
Remove flag --incompatible_remap_main_repo
45ec6ea 
It's on by default since Bazel 2.0, and the flag is now going away.

bazelbuild/bazel#7130
@laurentlb laurentlb mentioned this issue Jan 15, 2020
Merged
@laurentlb laurentlb mentioned this issue Jan 15, 2020
Merged
laurentlb added a commit to laurentlb/envoy that referenced this issue Jan 15, 2020
@laurentlb
Remove flag --experimental_remap_main_repo
9f8f5a7 
It's on by default since Bazel 2.0, and the flag is now going away.

bazelbuild/bazel#7130
Signed-off-by: Laurent Le Brun <laurentlb@gmail.com>
mattklein123 pushed a commit to envoyproxy/envoy that referenced this issue Jan 15, 2020
@laurentlb @mattklein123
Remove flag --experimental_remap_main_repo (#9686)
07fa5e0 
It's on by default since Bazel 2.0, and the flag is now going away.

bazelbuild/bazel#7130
Signed-off-by: Laurent Le Brun <laurentlb@gmail.com>
laurentlb added a commit to bazelbuild/bazel-skylib that referenced this issue Jan 16, 2020
@laurentlb
Remove flag --incompatible_remap_main_repo (#227)
4b25373 
It's on by default since Bazel 2.0, and the flag is now going away.

bazelbuild/bazel#7130
@aiuto aiuto mentioned this issue Apr 27, 2020
Merged
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@mboes mboes mentioned this issue Apr 6, 2021
Closed
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
ngiloq6 added a commit to ngiloq6/bazel-skylib that referenced this issue Aug 17, 2024
@ngiloq6 @c-parsons
Get docs working again. (#165)
5df1ffd 
- Update to newer version of stardoc.
- Make lib/selects.bzl stardoc compatible. There must be a block description before Args:

Docs now generate with
    bazel build --incompatible_remap_main_repo docs:*

See bazelbuild/bazel#7130 for reasons.
ngiloq6 added a commit to ngiloq6/bazel-skylib that referenced this issue Aug 17, 2024
@ngiloq6
Remove flag --incompatible_remap_main_repo (#227)
96fcb45 
It's on by default since Bazel 2.0, and the flag is now going away.

bazelbuild/bazel#7130
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@aehlig aehlig

Labels
incompatible-change Incompatible/breaking change P1 I'll work on this now. (Assignee required) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests