Fork of rules_ruby

[alexeagle]

Every Bazel user of this repo depends on ruby, due to an eager load statement evaluated during Bazel's loading phase

protobuf/protobuf.bzl

Line 5 in 30f1575

load("@rules_ruby//ruby:defs.bzl", "ruby_library")

However, this doesn't depend on a canonical rules_ruby which could be placed in the Bazel Central Registry, rather it's a protocolbuffers-team specific fork:

https://github.com/protocolbuffers/rules_ruby

which all bazel users are getting in their workspace due to

protobuf/protobuf_deps.bzl

Line 115 in 30f1575

repo = "https://github.com/protocolbuffers/rules_ruby",

This seems like a pretty major tech debt in this repo, and inhibits the task of providing protocol buffers on Bazel's registry, as I don't think we want your fork to be registered as the canonical rules_ruby, since you probably aren't offering to take the maintenance burden.

Note that the current entry https://registry.bazel.build/modules/protobuf/21.7 doesn't have this problem since the rules_ruby load statement didn't appear until later, introduced by #10525

I'll try cutting this load by moving everything ruby-related under the //ruby package. It still means bzlmod users won't be able to use the ruby well-known-types, but at least it makes the dependency graph satisfiable.

[alexeagle]

@mkruskal-google maybe you could give some more context about the decision to fork rules_ruby and whether you had any long-term plans for getting off that fork, or finding a maintainer for it?

[mkruskal-google]

The reason we forked this is because we couldn't find any canonical rules_ruby. IIRC at the time there was some issue with bazelruby's. I vaguely recall it being deprecated/unmaintained? or maybe it wasn't endorsed by Bazel?

Anyway, if there is a canonical rules_ruby now we'd be happy to switch to it (and maybe upstream our changes), although it would likely take some time (@zhangskz FYI). Would renaming this to something more clearly internal unblock this for now?

[alexeagle]

I don't think the situation has improved that there's a single canonical rules_ruby. I just learned that the selenium team has Yet Another One https://github.com/p0deje/rules_ruby

Renaming is only slightly helpful to disambiguate "this is the rules_ruby maintained by the protocolbuffers team". The problem will remain that yours will be the only rules_ruby on the Bazel Central Registry, which will appear to users to be the canonical one. Then you have a really big gap between the level of investment and maintenance that users will expect, vs. what you intend to provide (you call it "clearly internal" but it's not internal at all since all protobuf users depend on it)

[alexeagle]

I think the ideal answer is for the protobuf repo to have fewer language-ruleset dependencies. I'd like to explore the design space of how we could have no rules_ruby here at all, yet still generate .rb files and expose them with generic targets such that it's still possible (though maybe less ergonomic) for a rules_ruby user to use them in their ruby_library.

Do you have any "downstream" project that consumes the ruby WKT where I could verify whether some protobuf change can still work for users?

[mkruskal-google]

I don't know of any downstream projects using ruby (and I would expect most don't use Bazel), but our CI is heavily dependent on rules_ruby to actually test it. We do generate the .rb sources too here, although I'm not sure that helps much here

[mkruskal-google]

I think the best answer here would be for Bazel folks to converge on a canonical rules_ruby, and then have people migrate to it. Having none of them in the central registry seems like a big problem

[alexeagle]

See the linked issue for that convergence. Maybe it can be funded by the rules authors SIG.

As a short term answer, if you really only need a rules_ruby in order to test with CI, then I think we should do a refactoring so that it's a "dev dependency" and not exposed to protobuf's users. Something like #14570

[kigster]

I'd be more than happy to move bazelruby/rules_ruby to the main org.

[alexeagle]

I have been working on rules_ruby for the last week, I'm disappointed no one from the protobuf team replied here to indicate you had a different solution in mind.

[kigster]

I had no idea there were so many forks. Honestly when I started this project I was hoping Yugui would be my partner in crime :) But she ended up living in Japan and is very busy with something completely not Bazel :) Konstantin Gredeskoul CEO & Principal Consultant ● ReinventONE Inc ● https://reinvent.one/ ● (415) 265-1054

…

On Tue, Nov 21, 2023 at 12:17 PM Alex Eagle ***@***.***> wrote: I have been working on rules_ruby for the last week, I'm disappointed no one from the protobuf team replied here to indicate you had a different solution in mind. — Reply to this email directly, view it on GitHub <#14569 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB7PDRA4EEC6XYBD2YQ7X3YFUD67AVCNFSM6AAAAAA6YGV3W2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRRGYYTOMRWGU> . You are receiving this because you commented.Message ID: ***@***.***>

[mkruskal-google]

Hey Alex, sorry I didn't realize you were actively working on this. I built off your draft PR after we had an internal discussion about how to handle this.

Long-term, we'd like a canonical rules_ruby to use. But until then, leaving this as a dev-only dependency seems reasonable to unblock bzlmod

[alexeagle]

Note, there is https://registry.bazel.build/modules/rules_ruby now, as a result of my work on this issue :)

Also, @mkruskal-google WDYT about archiving protocolbuffers/rules_ruby so that it's clear that it's an unmaintained dead-end?

[mkruskal-google]

It's not really unmaintained, we're depending on it for our tests. Once there's a suitable replacement I'd be thrilled to remove it though :)

[alexeagle]

@mkruskal-google got it - we now have https://github.com/bazel-contrib/rules_ruby so that's our long-term goal, I imagine there are a few things missing to get to feature parity along with the dozen commits you had in your repo on top of the fork.