Add MODULE.bazel to support bzlmod

[Vertexwahn]

Life with Bzlmod is easier if every dependency provides a MODULE.bazel file. Therefore, the main purpose of this PR is to introduce a MODULE.bazel file in googletest. The MODULE.bazel can coexist with the WORKSPACE file. Users have to enable bzlmod via --enable_bzlmod flag (more details to the Bzlmod migration plan can be found here).

This PR is similar to #4118 (review)

Differences:

• Uses newer versions of modules
• Uses archive_ovrride to support live at head philosophy
• Update checkout action (v3 -> v4) in GitHub workflow
• Reformates old WORKSPACE file using buildifier

Further remarks:

• module_dot_bazel.patch is needed since abseil-cpp does not provide a MODULE.bazel file unit now - this is a chicken egg situation between the public GitHub repos of googletest and abseil

I recommend closing #4118 (review) and merging this PR

[Vertexwahn]

@derekmauro Please review!

[derekmauro]

This seems to almost work. I think where this approach fails is when we try to do a release, because of the chicken-egg problem with Abseil.

The GoogleTest and Abseil releases are coordinated. When we release GoogleTest, we bump all versions to the latest in the WORKSPACE file, and do the release, like normal. Then we do the Abseil release, using changing the WORKSPACE file to use the GoogleTest release. If you want to use them both, you just create a WORKSPACE file with both released versions, and they will work together.

The chicken-egg problem only happens with the MODULE.bazel file. Since the versions must be named before they can be referred to, only one of GoogleTest and Abseil can point to the latest released version. Unless I've missed something, any user of both would have to override at least one of them.

It almost seems that the best solution is to keep the patch in the Bazel Central Repository where the versions can be updated simultaneously after being published. We can add this step to our release process and officially manage it, if there is no other solution.

/cc @meteorcloudy

[meteorcloudy]

Can we also upstream the MODULE.bazel to abseil-cpp? Then you won't need to add a patch for the archive_override.

As long as both googletest and abseil-cpp are published to the BCR, the end users can always specify the latest version for both of them, and Bzlmod will resolve the dependencies. I don't see any chicken-egg problem?

[Vertexwahn]

@derekmauro Should I open a PR on abseil-cpp?

[derekmauro]

As long as both googletest and abseil-cpp are published to the BCR, the end users can always specify the latest version for both of them, and Bzlmod will resolve the dependencies. I don't see any chicken-egg problem?

Sure, that works. But what if you are only using GoogleTest directly? You might not even know that you depend on Abseil.

[derekmauro]

@derekmauro Should I open a PR on abseil-cpp?

Let's figure out how to resolve this first.

[meteorcloudy]

Sure, that works. But what if you are only using GoogleTest directly? You might not even know that you depend on Abseil.

I assume googletest will introduce a suitable abseil version automatically? It might not be the latest one, but it should work with googletest?

[derekmauro]

I assume googletest will introduce a suitable abseil version automatically? It might not be the latest one, but it should work with googletest?

What does it mean to "introduce a suitable abseil version automatically"?

[meteorcloudy]

In googletest's MODULE.bazel file, depend on abseil-cpp via a bazel_dep statement.

[derekmauro]

I think this misses the point I made above. Let me try an explicit example.

Abseil and GoogleTest are both at version 1.
Abseil introduces feature X in a dev commit.
GoogleTest uses feature X in a dev commit. It is able to do this because it uses the archive_override feature to support live at head philosophy.
GoogleTest introduces feature Y in a dev commit.
Abseil uses feature Y in a dev commit. Again, it is able to this because it uses the archive_override feature to support live at head philosophy.

Now it comes time to release Abseil and GoogleTest version 2.
If I release GoogleTest version 2 first, I can't refer to any released version of Abseil in MODULE.bazel, because none of them have feature X.
If I release Abseil version 2 first, I can't refer to any released version of GoogleTest in MODULE.bazel, because none of them have feature Y.

[meteorcloudy]

Thanks for the example, I see the problem now.

I guess, we need to decouple the release processes and increase the frequency to address this issue.

Imagine if you release a new version every time you had a new commit to each of the libraries, we won't have this problem since this will fallback to the WORKSPACE use case (where you can point to any commit).

But that's the extreme case, we only need to have a new abseil version once feature X is introduced so that googletests can depend on a released version of abseil and vice versa.

Do you think this would be feasible? I'm not sure how expensive it is to make a new release for those two projects.

[derekmauro]

Support has been added in 6a59382. We will publish support to BCR after the next release.