bazel-contrib / rules_ruby Goto Github PK

There's a TODO introduced, see thread:
#17 (comment)

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency bazel to v7

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency io_bazel_stardoc to v0.6.2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Note, this is "nice to have", maybe not a requirement for a 1.0 of rules_ruby.

Use case: I'm in a monorepo where one app has 1000 giant dependencies. I write a little ruby tool for all developers to run, and it only needs one small gem, call it "mygem".

I don't want users of my tool to have to wait to download all the giant dependencies. So the bundler install would have to be decomposed such that each gem goes in its own external/ repository, and then in my BUILD files instead of depending on "all gems" like @bundler//:all, I would depend on @bundler_mygem. That way the other gems aren't referenced in the build graph and so they aren't fetched.

Bazel 7 will be released in the next few weeks and enables bzlmod by default.

These rules should be tested with bzlmod and be published to the Bazel Central Registry with each release.

Have you seen something like this?

This error feels to me like the repository rule is trying to write to some global location on my disk, and maybe we need to set an environment variable like XRUBY_RUBYLIBDIR somewhere so the MRI build process is okay with running in some read-only sandbox?

I'm on Linux, tried ruby 3.0.6 and 3.2.2, get an error like the following

x86_64-linux-fake.rb updated
external command failed with status 2

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19.5M  100 19.5M    0     0  7329k      0  0:00:02  0:00:02 --:--:-- 7329k
./tool/mkconfig.rb:272:in `write': Permission denied @ io_write - <STDOUT> (Errno::EACCES)
        from ./tool/mkconfig.rb:272:in `print'
        from ./tool/mkconfig.rb:272:in `<main>'
make: *** [uncommon.mk:879: .rbconfig.time] Error 1
make: *** Waiting for unfinished jobs....

BUILD FAILED (Ubuntu 20.04 on x86_64 using ruby-build 20231114)

I do have a system ruby already

$ ruby -v
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]

Currently the approach for testing different interpreters is for CI to Run echo 'RUBY_VERSION = "3.1.4"' > ruby_version.bzl but under MODULE.bazel this .bzl file cannot be load()ed, so we have a fixed interpreter version.

Without installing any ruby stuff on my machine, I'd like to be able to edit the Gemfile and Gemfile.lock files in a correct way by running sth like bazel run @ruby//:gem -- install rails, without worrying about version skew with a different version of gem than Bazel will use.

The psych gem (version 5.1.1.1) fails to install on my machine, log contains:

conftest.c:3:10: fatal error: yaml.h: No such file or directory
    3 | #include <yaml.h>
      |          ^~~~~~~~
compilation terminated.
checked program was:
/* begin */
1: #include "ruby.h"
2: 
3: #include <yaml.h>
/* end */

As documented here, for example
https://github.com/sparklemotion/nokogiri#native-gems-faster-more-reliable-installation
there's a way to start from a pre-compiled native gem instead. I think most Bazel users should be using this to achieve reproducible builds.

(Of course, you could also imagine a cc_library to build the C extension, but then we're swapping out part of the bundle installer which is a bigger project)

Ideally the ruleset should use rctx.download[_and_extract] to fetch dependency gems so that:

• they are cached in the bazel repository cache
• configuration of the Bazel downloader can be used, i.e. to ensure they are fetched from a corporate proxy
• bazel shows more information about the fetching phase than just "running bundler"
• we can apply patches to third-party gems in a similar way as other bazel fetches may be patched

I noticed that when running bazel build //some/non/ruby/target, the ruby interpreter is always downloaded even if the target does not depends on it.

It looks like rb_download always performs the download before registering the toolchain. I believe this is different from the recommended bazel toolchain setup, which only downloads the toolchain on a per-need basis (i.e. if rb_* rules are in the build action graph).

bundle install passes in PATH variable, which can head to non-hermetic builds.

In our case, we had $GEM_HOME/bin:$BUNDLE_PATH/gems/bin: in our PATH variable that resulted in gems getting downloaded in a different directory.

May be better to remove PATH altogether.

This would be useful to configure build flags for gems:

rb_bundle(
  env = {
    "BUNDLE_BUILD__GRPC": "--with-ldflags=-Wl,-undefined,dynamic_lookup"
  }
)

We had a red build on the Bazel Central Registry:
https://buildkite.com/bazel/bcr-presubmit/builds/2569#018c02af-083a-4eff-88ba-7f8ccbae9ff5

I'll disable Windows for now to land that PR, but I suspect this is trivial to fix for the next release?

The runfiles produced by an rb_binary target ought to be self-contained, so that binary can be used as the tool in a subsequent action that uses a Ruby program to transform some input files into files under bazel-out.

I think this is currently not working, here's a PR with a demo that I'd expect to work:
#15

Current rb_binary implementation depends on Gemfile to be listed as a transitive source in order to set BUNDLE_GEMFILE env var. This is not super obvious. Given that we have already specified Gemfile in rb_bundle, a more explicit way to express this could be introducing a link_bundle_gems function for this, something like:

load("@bundle//:defs.bzl", "link_bundle_gems")
link_bundle_gems(name = "gems")

rb_binary(
    name = "add-numbers",
    args = ["1"], 
    main = "add.rb",
    deps = [
         ":gems",
    ],
)

rb_binary() targets are not run via bundle exec so local gems are not visible to them. See https://github.com/jgao54/rules-ruby-issue-repro.

Is there a way to support installing a specific version of bundler when setting up the ruby toolchain? Currently this is not configurable, afaik; instead the default version of bundler corresponding to the ruby version is used.