Not bundling @platforms, or at least not downgrading it?

[cpsauer]

Hi Bazel Go folks :)

I ran into a hitch that I thought I should raise for discussion. To make a long story short: My team had stumbled around for a bit before someone helped us realize that, by default, rules_go was downgrading bazelbuild/platforms dependency below the version bundled with Bazel.

[For more details: _maybe doesn't capture the existence of the built in platforms. An older version of rules_go was getting pulled in by the latest gRPC, and that version of rules_go was overriding the latest built-in platforms with a much older, problematic version of platforms. While this can be worked around by manually importing platforms, I suspect I'm not the last person to get tripped up by this. That is, with the current behavior, today's rules_go is likely to be tomorrow's out-of-date version, causing confusion when it breaks unrelated parts of someone else's build.]

I'm writing to ask if rules_go would consider not downgrading the built in platforms.
Some options that occur:

• If it's okay to have a min bazel version of at least 0.28 for rules_go (readme says "a recent version of Bazel," which that is not), then maybe a good fix would be to just not bundle platforms in https://github.com/bazelbuild/rules_go/blob/master/go/private/repositories.bzl, since you can count on having a built in version. Update: Looks like the declared minimum version is 4.2.1, so this would be my vote.
• Otherwise, we could use https://github.com/bazelbuild/rules_go/blob/master/go/private/skylib/lib/versions.bzl to only pull in platforms if it's not bundled--working around the somewhat surprising behavior of _maybe not detecting builtins?
• [Or somehow detect the version of the build in platforms and only upgrade?]

Thanks so much for your consideration!
Chris
(ex-Googler)

[bizrad]

I think I'm seeing an issue related to this in my build after trying to move to 0.30.0
This is when I don't explicitly bring in the platforms http_archive with bazel 5.0.0

io_bazel_rules_go/go/platform/BUILD.bazel: no such target '@io_bazel_rules_go//go/platform:ios_386': target 'ios_386' not declared in package 'go/platform'

If I use platforms 0.0.5 then I get this error

io_bazel_rules_go/go/platform/BUILD.bazel: no such target '@io_bazel_rules_go//go/platform:ios_arm': target 'ios_arm' not declared in package 'go/platform' (did you mean 'ios_arm64'?)

[seh]

Have either of you found a workaround that doesn't require patching rules_go itself? Like @bizrad, I too tried puling in the "platforms" repository myself, but it doesn't help.

It's worth noting that for my targets, the one that fails involves a dependency on the modernc.org/libc Go module. The BUILD.bazel file generated for it includes a target with a "deps" attribute value that uses select against the "@io_bazel_rules_go//go/platform:ios_386" constraint, which Bazel doesn't recognize. Looking at the similar select clauses, this "ios_386" platform appears to be equivalent to a few others such as "darwin_arm," "ios_arm," and "linux_amd64," in that those use the same subset of potential dependencies.

Find that generated BUILD.bazel file here, with the "txt" extension tacked on to appease GitHub.

[seh]

Having run into this problem building on macOS atop an Intel CPU, I also tried building using Ubuntu Linux in a GitHub Actions runner. It yielded a similar error, but with different details, matching the earlier report here in #3071 (comment):

ERROR: /home/runner/.cache/bazel/_bazel_runner/942b68d1356faf2a2a72fec1ae43408c/external/io_bazel_rules_go/go/platform/BUILD.bazel: no such target '@io_bazel_rules_go//go/platform:ios_arm': target 'ios_arm' not declared in package 'go/platform' (did you mean 'ios_arm64'?) defined by /home/runner/.cache/bazel/_bazel_runner/942b68d1356faf2a2a72fec1ae43408c/external/io_bazel_rules_go/go/platform/BUILD.bazel
ERROR: /home/runner/.cache/bazel/_bazel_runner/942b68d1356faf2a2a72fec1ae43408c/external/org_modernc_libc/BUILD.bazel:3:11: errors encountered resolving select() keys for @org_modernc_libc//:libc

[seh]

Downgrading rules_go to version 0.29.0 allows our targets to build properly again.

[bizrad]

We actually had an issue with reproducibility in 0.29.0 related to cgo, so I pinned our version to a commit between 29 and 30 for now. I mentioned this over on #3070 (comment) and that is one fix to get a newer rules_go. However, it appears this issue is over in gazelle and how it dynamically makes the BUILD files in remote repos like you say.

Looks like a merge has happened to fix this, so we need a new version cut of gazelle or you can try using the latest commit of the main branch or patch the file.

MR to fix this: bazel-contrib/bazel-gazelle#1168
Problem file: https://github.com/bazelbuild/bazel-gazelle/blob/v0.24.0/rule/platform.go

I was able to build with the latest commit of gazelle, no idea how stable it is though.

git_repository(
        name = "bazel_gazelle",
        remote = "https://github.com/bazelbuild/bazel-gazelle.git",
        commit = "41b542f9b0fefe916a95ca5460458abf916f5fe5",
        shallow_since = "1646244992 -0500"
)

[cpsauer]

Heads all that I'd tossed up a PR proposing a fix a little while ago in #3076.
Not getting a lot of replies, but hopefully we'll get it in--or maybe another fix if they'd rather do something else.

[bizrad]

My builds are now working with bazel 5.0.0, rules_go 0.31.0 and gazelle 0.25.0.

[seh]

I found that the upgrade to gazelle version 0.25.0 did the trick. Thank you for the recommendation, Brad.

[cfife-btig]

I'm running on Bazel 6.3, Gazelle 0.25 and rules_go 41.1 but have had no luck.

I seem to be experiencing the exact same issue as mentioned by @seh. I was trying to pull in a library that had modernc as a dependency and was complaining that ios_386 platform wasn't in the list of platforms. I just gave up and switched to a different library that didn't use modernc. In our case, we don't really have any interest in supporting ios or arm so I'm not sure if there's a way to just ignore those platforms.

While I roughly understand the issue, I don't understand why the modernc dep is getting generated with a different set of platforms than rules_go uses? If rules_go doesn't generate the modernc deps, then what does?

[cfife-btig]

I take it back, upgrading to a version past 0.24 of Gazelle worked for me as well. I just hadn't updated my sha256 so it was still downloading 0.24 without me knowing...