bazel: 2.0.0 -> 2.1.0

[jpgneves]

Motivation for this change

The official Bazel wrapper script included from version 2.0.0 onwards enforces the actual bazel binary (previously named bazel-real in this package) has the following naming convention, if the root of your Bazel project contains a .bazelversion file: bazel-${version}-${os}-${arch}.

This modifies output binary name and, while we're at it, upgrades Bazel to 2.1.0.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[uri-canva]

Looking at the current implementation of the script on master, it doesn't enforce that naming convention for the binary, it still supports calling it bazel-real as well: https://github.com/bazelbuild/bazel/blob/59d7864b3a39008e6b4d1447abcdc59cd9906e88/scripts/packages/bazel.sh

In that case the .bazelversion becomes a check that makes sure the version you're running matches it.

[Profpatsch]

In that case the .bazelversion becomes a check that makes sure the version you're running matches it.

That looks like what we should be doing.

[andir]

Please don't just update this version. Does 2.0 remain compatible with 2.1 in all cases? If not we should consider having another attribute within nixpkgs. The update to Bazel 2.0 already caused some breakage that we didn't get rid of yet. See the relevant conversations in #76851 and my WIP PR #80953.

[Profpatsch]

bazel promises no backwards-compatible changes for three months at a time

If they release a breaking change, they bump the major version.

[Profpatsch]

This modifies output binary name and, while we're at it, upgrades Bazel to 2.1.0.

Let’s put this in another commit.

[jpgneves]

Will do! Apologies for the messy intermixing of changes. Should I close this PR and resubmit separate ones, or is it sufficient to create a new one with the version change?

[Profpatsch]

Should I close this PR and resubmit separate ones, or is it sufficient to create a new one with the version change?

It’s fine if you pull it out in a separate commit, they can both be in this PR.

[Profpatsch]

related comment in the original issue:

#80950 (comment)

[Profpatsch]

So I guess as long as we have a normal bazel binary and the versioning is what bazel expects, it’s better to be as specific as possible.

[Profpatsch]

Once the two commits are split, this is good to go. 👍

[Profpatsch]

@GrahamcOfBorg build bazel.tests

[jpgneves]

Regarding the failed tests on darwin, I do not have a machine where I can work to fix the issue, so I'd appreciate any assistance in figuring it out, if it's a blocker (which it sounds like it is). :)

[Profpatsch]

@kalbasit you seem to have fixed the protobuf test last time, could you take a look?

[uri-canva]

The failure I'm getting on darwin is the one that was fixed in #80635.

[uri-canva]

Rebased on current master (b1ec189) it works.

[jpgneves]

Rebased it on current master right now.

[Profpatsch]

cool