Migrating from bazelruby/rules_ruby

[JasonLunn]

I'm attempting to migrate from the similarly named but no-longer supported https://github.com/bazelruby/rules_ruby but running into trouble in a couple of places.

1. Understanding how to detect what Ruby platform is active from Bazel rules.

Today, I use select() to find out if I'm building for a JRuby or a CRuby, and build the native portion of the gem extension that is appropriate:

select({
        # Platform native implementations
        "@rules_ruby//ruby/runtime:config_jruby": ["gem_java.jar"],
        "@platforms//os:osx": ["gem_c.bundle"],
        "//conditions:default": ["gem_c.so"],
    })

This allows me to build the Jar if I'm on JRuby on any OS, compile the native code as a OSX bundle if I'm on macOS, and otherwise compile the native extension as normal.

This rules_ruby doesn't expose runtime the same way as the one I'm migrating from, so I'm curious how to achieve a similar outcome.

2. Gemfile.lock required?

We don't check in a Gemfile.lock into our repo, but rb_bundle_fetch() requires it. We're used to the Gemfile.lock being created on the build host for the specific platform and architecture we're building for at the time. Is there a way to generate the Gemfile.lock using a bazel rule rather than expecting it to already exist?

[p0deje]

1. I will check how bazelruby was doing this and attempt to implement a similar mechanism.
2. It's required to have Gemfile.lock for rb_bundle_fetch and I don't see any way to implement it w/o having a lockfile. Why don't you check it into the repository? It's currently recommended by Bundler both for applications and libraries.

[p0deje]

In 0.16.0 you can now use:

select({
    "@ruby//engine:jruby": ["gem_java.jar"],
    "@platforms//os:osx": ["gem_c.bundle"],
    "//conditions:default": ["gem_c.so"],
}),

[JasonLunn]

1. Thanks!
2. What prevents the underlying call to bundle install from generating the Gemfile.lock from Gemfile as normal? Historically we didn't check in a Gemfile.lock because it captures platform-specifics of the gem dependencies. I will double check whether our support matrix requires us to support ruby/rubygems before platform support was added.

[p0deje]

What prevents the underlying call to bundle install from generating the Gemfile.lock from Gemfile as normal? Historically we didn't check in a Gemfile.lock because it captures platform-specifics of the gem dependencies. I will double check whether our support matrix requires us to support ruby/rubygems before platform support was added.

The main issue with calling bundle install is that toolchain may not be installed yet so it's not hermetic (i.e. can use system Ruby or force installing of Ruby when loading WORKSPACE. It also won't respect Bazel caching and its configuration for downloading files (auth, proxy, etc). It also won't work with Remote Build Environment because bundle install runs on the host machine rather than the guest.

To cut it short, no rules should ever call to toolchains during WORKSPACE/MODULE.bazel loading. If you check in Gemfile.lock and use rb_bundle_fetch(...), the gems will be fetched by Bazel and bundle install will be run as a regular build target (bazel build @bundle).

At this point you have an option of using rb_bundle(...) repository rule which doesn't request Gemfile.lock. However, it's deprecated due to the reasons above and I strongly recommend checking Gemfile.lock into the repo. We did it at some point in Selenium (https://github.com/SeleniumHQ/selenium/blob/trunk/rb/Gemfile.lock) though it does have plenty of platform-specific gems.