Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-java, googleapis-python, googleapis) have been updated in this PR. Please review the changes.

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-grpc-cc, googleapis-grpc-java, googleapis-java, googleapis-python, googleapis) have been updated in this PR. Please review the changes.

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-grpc-java, googleapis-java, googleapis-python, googleapis) have been updated in this PR. Please review the changes.

Another thing which just came to my mind: Uploading new versions will become much more work with this approach. This is especially relevant since we don't have active maintainers for this package and are even further away from release automation. So it will become less likely that people contribute version updates.

We should avoid making updates more complicated, but I don't see why this would make it so. Instead of the patches, there are now a few overlay files, but that's the only change I see. The "flavor" modules only need new versions if the targets generated in googleapis change in a fundamental way. Do you see other downsides to this approach?

I'm thinking of adding a tool to the repo that creates a new version of an existing module by symlinking over files that haven't changed and replacing the old version with the new version in module files, URLs and prefixes. That should make it very easy to update googleapis, regardless of which approach is used. What do you think about that?

We should avoid making updates more complicated, but I don't see why this would make it so. Instead of the patches, there are now a few overlay files, but that's the only change I see. The "flavor" modules only need new versions if the targets generated in googleapis change in a fundamental way. Do you see other downsides to this approach?

I raised everything which was on my mind for now in #3437 and here.

I'm thinking of adding a tool to the repo that creates a new version of an existing module by symlinking over files that haven't changed and replacing the old version with the new version in module files, URLs and prefixes. That should make it very easy to update googleapis, regardless of which approach is used. What do you think about that?

It would be great if such tool would also handle patches (at least in cases where it applies with somewhat larger fuzzing for moved lines and skip already applied patches). It could create a temporary git repo for this for example (git init) and delete the .git folder on cleanup.

@meteorcloudy @Wyverald Friendly ping

Looks good to me, but wait for @Wyverald to confirm this is the way to go.

Sorry about the delay -- this slipped my radar and I've been distracted by other work. I'll take a look later today.

While I really like this approach to the extensions, I'm actually wondering if it's better to make a bigger break to simplify things. What I mean by that is not having googleapis provide language-specific targets and only provide proto_library targets.

The main reason I see for having googleapis provide the language-specific targets at all is to ensure that there's no duplication of generated code. Language-specific proto library rules should all be implemented with aspects though, which inherently avoids the duplication problem.

The downside of course is that there's a much bigger change for downstream users. Additionally, it would be best if the above change could be made on googleapis itself rather than having someone maintain that as patches to BCR.

@SanjayVas As much as I would like that, it seems almost impossible without cooperation from upstream and as we have learned, they don't care about Bazel at all.

Hey, I know I promised to take a look today, but this is quite a big change and I'd like to understand the context better before making a call -- I'll continue to read this (and @mering's previous PR) tomorrow.

On the other hand, this PR suffers a similar (minor) problem to that PR, in that there's no "strict deps" for registration

Yes, this is a caveat that is relevant, but I also don't see a way to avoid this.

There's a fair amount of code in this PR, all in overlay files. I think this is the sort of stuff that would benefit from being in an actual repo (easier to review, etc).

I'm still not sure what I prefer, but this approach has an important drawback: It gets much harder to contribute new googleapis versions. Since upstream is not going to support this, we would need a dedicated bazel-contrib repo that hosts the new files. But as a result, external contributors would need to send a PR against that repo, get it reviewed and merged. This makes the maintainers of that new repo a bottleneck to contributions. As I'm not an active user of googleapis and upstream may break us at any time, I wouldn't really want to be in that position.

If we keep the sources in the BCR, the users of the module are in more direct control over the module (assuming we always have sufficiently many maintainers). Since the overlays should change only very rarely (essentially someone adds a new googleapis-foo module) and new versions without changes to them can symlink everything over, I don't find this situation too bad for the BCR experience.

One of the requests from the protobuf team was support for a "nodep" bazel_dep; that is, specification for the minimal required version of a certain module, without actually introducing a dep on it (so the requesting module cannot use it, even if the dep is present in the dep graph).

Yes, that's the missing piece to making this design maintainable in the long run - without it, we wouldn't have a way to force new googleapis-foo versions.

I'm still not sure what I prefer, but this approach has an important drawback: It gets much harder to contribute new googleapis versions.

To be clear, the googleapis module would stay (mostly) the same -- its sources will still come from https://github.com/googleapis/googleapis. It's just all the googleapis-* flavor modules, and a central googleapis-registry module that contains the module extension, that will come from the bazel-contrib repo. googleapis's MODULE.bazel file in BCR would then use the extension from googleapis-registry.

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis-cc, googleapis-go, googleapis-grpc-cc, googleapis-grpc-java, googleapis-java, googleapis-python, googleapis-rules-registry, googleapis) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

This is now stacked on #3786, which adds the separate modules.

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (googleapis) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.