incompatible_fix_package_group_syntax

[brandjon]

Description: This flag changes the behavior of the string "//..." in package_group's packages attribute. Previously, this was treated as including all packages, everywhere, in the package_group. With the flag enabled, it now means all packages in the default repo (i.e. the repo where the package_group lives).

Migration: Wherever the old behavior is desired, replace "//..." with "public", which is the new way to refer to all packages in any repo. The value "public" (and its sibling, "private") is available regardless of whether this flag is enabled.

Note that in .bzl visibility, "//..." always behaves as if this flag were enabled. So without the flag enabled, this value will mean two different things depending on where it appears.

Rationale: This is more consistent with other possible package specifications. For instance, "//pkg/..." means all packages underneath //pkg in the default repo, not all packages underneath //pkg in any repo. Likewise, "//" means the root package of the default repo, not the root package of any repo. Without this change, there is no easy way to grant visibility to only the current repo via a package_group (although a visibility attribute could use "//__subpackages__").

[brandjon]

This flag doesn't actually exist at head yet, will submit the code shortly. Then we'll check the pipeline and confirm it's feasible to flip for 6.0.

[meteorcloudy]

Bazel 6.0 is scheduled to be cut on Oct 10th, do we have enough time to implement and flip this?

[brandjon]

I believe so. I hit a snag that I need to create a second incompatible flag to flip alongside it, but I don't believe that'll stop me.

[meteorcloudy]

I see, please add migration-ready label when the flags are available at HEAD so that the flags get tested in https://buildkite.com/bazel/bazelisk-plus-incompatible-flags 's nightly run, you can also trigger a downstream test for flipping those flags.

[meteorcloudy]

Almost all downstream projects are broken by this flag, check https://buildkite.com/bazel/bazelisk-plus-incompatible-flags/builds/1291

E.g.

(01:11:47) ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/8e0b5ed0fa259a0e5b9840e22648f47d/external/bazel_tools/tools/android/BUILD:524:14: Cannot use new "//..." meaning without allowing new "public" syntax. Try enabling --incompatible_package_group_has_public_syntax or disabling --incompatible_fix_package_group_reporoot_syntax.
(01:11:47) ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/8e0b5ed0fa259a0e5b9840e22648f47d/external/bazel_tools/tools/android/BUILD:529:14: Cannot use new "//..." meaning without allowing new "public" syntax. Try enabling --incompatible_package_group_has_public_syntax or disabling --incompatible_fix_package_group_reporoot_syntax.
(01:11:47) ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/8e0b5ed0fa259a0e5b9840e22648f47d/external/bazel_tools/tools/android/BUILD:534:14: Cannot use new "//..." meaning without allowing new "public" syntax. Try enabling --incompatible_package_group_has_public_syntax or disabling --incompatible_fix_package_group_reporoot_syntax.
(01:11:47) ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/8e0b5ed0fa259a0e5b9840e22648f47d/external/androidsdk/BUILD.bazel:13:25:

[meteorcloudy]

Looks like many breakages are within bazel_tools, so probably should be easy to fix, but not sure if any downstream projects also need to be fixed.

[brandjon]

Yes, it looks like bazel_tools needs to atomically switch to the new public syntax, and then we can see if there are any remaining breakages downstream (using runs that also set --incompatible_package_group_has_public_syntax).