[Bazel CI] Error with Label '@@platforms//host:extension.bzl' is invalid because 'host' is not a package

[sgowroji]

CI: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3769

Platform: Ubuntu, MacOs, Windows

Logs:

ERROR: �[0merror loading package '': Label '@@platforms//host:extension.bzl' is invalid because 'host' is not a package; perhaps you meant to put the colon here: '@@platforms//:host/extension.bzl'?

Culprit: 74c8ca4

CC Greenteam @fweikert @meteorcloudy @Wyverald

Few downstream projects are failing with below error

1. Gerrit
2. Kythe
3. Stardoc
4. Protobuf
5. rules_dotnet
6. rules_foreign_cc
7. rules_go
8. rules_haskell

[brentleyjones]

They need to depend on the newer @platforms. We fixed this in apple_support here: bazelbuild/apple_support@a1c4ec2.

[Wyverald]

This is an unfortunate issue only with WORKSPACE -- Bazel itself already ships with the latest @platforms bundled, but there's no way to "force" that to be the version to be used. With Bzlmod, bazel_tools depends on the latest platforms, so there's no issue.

[Wyverald]

This also means that 74c8ca4 is not cherry-pickable back to 7.2.0. Hmm... I might need to come up with some halfway solution here.

[fmeum]

Could we just keep the default value of --host_platform as is for WORKSPACE (i.e., depending on the --enable_bzlmod flag)? Realistically speaking all WORKSPACE projects would otherwise have to manually bump platforms and also add the separate setup step for the generated repo. Since WORKSPACE users won't benefit from the future improvements to constraint registration, that pain won't pay off for them anyway.

[Wyverald]

Changing the flag default based on another flag sounds pretty error-prone. But I think I can safely change what @bazel_tools//tools:host_platform aliases to based on the value of --enable_bzlmod.

also add the separate setup step for the generated repo.

This part is unnecessary; it's done in the WORKSPACE suffix. In fact it's what's causing the current breakage...

Since WORKSPACE users won't benefit from the future improvements to constraint registration, that pain won't pay off for them anyway.

I mostly wanted to deprecate the native repo rule. I guess that's still doable, we just need to ship a copy of @@platforms//host:extension.bzl in Bazel 7.x. Which isn't the end of the world, but the setup is getting quite convoluted.

[meteorcloudy]

Downstream projects are still failing: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3783

[fmeum]

The problem is that @local_config_platform//:constraints.bzl reexports the constraints that now live in @platforms, which fails if the platforms repo isn't version 0.0.9 or higher.

We could reexport the constraints from the fake platforms repo instead when using WORKSPACE only. Maybe we also need to do this for the host alias?

[meteorcloudy]

Looks like there are still platforms related failures in https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3797

[meteorcloudy]

Oh, the fix was just submitted one hour ago, let's wait for another day.

[Wyverald]

Still not fixed... https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3801#018ef488-87d2-4d8d-ac56-65762421b4a0

Looks like this still fails when Stardoc and/or android_sdk_repository are involved. Will take a look.

[Wyverald]

I've sent a change internally to fix the android_sdk_repository issue.

Regarding Stardoc, there honestly isn't a good fix... We can upgrade rules_dotnet to use a newer Stardoc (which properly uses starlark_doc_extract), but that requires setting up a bzl_library/filegroup target for the constraints.bzl file in local_config_platform, which is very hard to do in a backwards-compatible manner. Will need to think about it more.

[meteorcloudy]

We need to move bzl_library into bazel_tools

bzl_library is currently in bazel_skylib, which is a dependency of everything. Can we do this in a backwards compatible way?

[Wyverald]

We specifically didn't want to introduce a dependency on skylib from @platforms, which doesn't have any dependencies right now. It's not as easy as "just add skylib" because there's still WORKSPACE :)

[meteorcloudy]

Oh, I meant making the change of moving bzl_library from bazel_skylib to bazel_tools itself to be backwards compatible. I guess we need to add some redirects to bazel_skylib to make sure everyone is using the same bzl_library?

[Wyverald]

ah, I see -- yes, that's the plan. bzl_library in bazel_skylib would just be an alias for its counterpart in bazel_tools.

[Wyverald]

See also bazelbuild/bazel-skylib#495 which would serve as a stop-gap in the meantime.

[meteorcloudy]

Nice! /cc @comius

[fmeum]

ah, I see -- yes, that's the plan. bzl_library in bazel_skylib would just be an alias for its counterpart in bazel_tools.

Isn't that difficult to pull off since loads are entirely static? For bzl_library in bazel_skylib to be an alias of the one in bazel_tools, we would either need to add a minimum Bazel version requirement to that version of skylib or introduce repo rules with generated loads. The latter would probably break with WORKSPACE though since many skylib users don't call its dependency macro (which so far only registers a toolchain for unit tests).

[meteorcloudy]

we would either need to add a minimum Bazel version requirement to that version of skylib or introduce repo rules with generated loads.

I think this is also the concern Ivo raised to me. I don't have great answers, maybe we can backport the bzl_library to bazel_tools change in older Bazel LTS releases to make it easier for users to adapt? So basically, users have to migrate to the latest minor Bazel releases to use the latest bazel_skylib, which should be easy theoretically.

[Wyverald]

All green now!