The cross-build existed already before but was just broken. buildRubyGems will be more complex since we would need something like https://github.com/rake-compiler/rake-compiler

After a very long git bisect session, I found that this commit, more specifically the --destdir $GEM_HOME is responsible for breaking bundlerEnv in cases where the ruby (minor) version is not the latest one. I tested it with https://git.immae.eu/?p=perso/Immae/Config/Nix.git;a=tree;f=nixops/modules/websites/tools/diaspora;hb=61199e9367515ec28f2a24903ea12a7b6747c9c0 , but all my bundler applications in a similar situation (not the latest ruby version) broke at once after an upgrade, and reverting the destdir addition makes them work again ( https://git.immae.eu/?p=perso/Immae/Config/Nix.git;a=commitdiff;h=3345e58db4e8364a9561dc3d488da2438aca982a ).

The error only happens at runtime (in the systemd service, defined in default.nix in my example), while similar commands at build time (for instance railsRoot in diaspora.nix) work correctly. I tried multiple options and flags in vain, but I may have missed the "right" way to use bundlerEnv that would make it work...

Before reporting it as a regression issue, I’d appreciate a confirmation that it is actually a regression and not just me misusing  bundlerEnv.

I'm hitting an issue relating to this change. Before this change, bundler was made available in the output, while after the change it doesn't. It seems related to how the bundled gems (site_ruby) stuff is now in probably erroneously nested subpaths of the output. See the following diff of the outputs with the commit, and with it reverted.

• https://gist.github.com/aff578283e627b5befcadee5cf909cb6

Though, I'm unsure whether this is really an issue or not, but it breaks what was previousy working, and (while quite late) the backport to 18.09 changes its behaviour compared to the branch off point.

Should bundle have been available there? Does it make sense when the globally available bundler might not be using the same ruby as a specific one? (Though other than closure size issues, not sure it's an issue.)

Though, one thing is clear, this breaks assumptions between 18.03 and 18.09 and apparently broke an assumption between the release of 18.09 and now :/.

@samueldr the symptom is the same for me, but I think it comes from hardcoded paths somewhere (see my comment above your). Does it appear only when you use a version of bundler that is different from the latest (currently 2.6) one? If so, you should try the "patch" that I quote there: #54303 (comment)

@immae I'm not using it with bundlerEnv, it's for providing bundler as an executable on the CLI, so the issue for me is the disappearance of bundler. Though, it might also be closely related to your issue, I just haven't really checked.

I actually jumped the gun here. I wasn't done with the complete testing and assumed that bundler + bundler deps installing would be fine.

With this merged, and a buildEnv:

buildEnv {
  name = "ruby-with-bundler";
  paths = [ bundler ruby ];
};

Installing using bundle install works fine as it did previously. Running the ruby thing doesn't.

Traceback (most recent call last):
        2: from bin/cap:15:in `<main>'
        1: from /nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require'
/nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- bundler/setup (LoadError)

While with this reverted locally it works fine. Ruby 2.6 (without this reverted) works fine too. This makes me think there really is a regression here.

Tried a build without --destdir $GEM_HOME and the native build's file listing is not identical to the previously working one.

diff --git a/pkgs/development/interpreters/ruby/default.nix b/pkgs/development/interpreters/ruby/default.nix
index e7aedfc0750..4d1775db8c7 100644
--- a/pkgs/development/interpreters/ruby/default.nix
+++ b/pkgs/development/interpreters/ruby/default.nix
@@ -146,7 +146,7 @@ let
         postInstall = ''
           # Update rubygems
           pushd rubygems
-          ${buildRuby} setup.rb --destdir $GEM_HOME
+          ${buildRuby} setup.rb
           popd

           # Remove unnecessary groff reference from runtime closure, since it's big

@immae if you're interested in trying.

Waiting on a cross aarch64 build to see. how it reacts.

Though, Quoting @Mic92

Without --destdir it tries to install gemspec files in buildRuby.

It is an issue, it won't build without --destdir; though confirming that a cross-built ruby will have the same deeply nested paths.

Here's where I'm at: making --destdir conditional to cross-compilation is not the way to go, since it would (AFAIUI) cause the same gemdir breakage, but only when cross-compiling. Played around with GEM_HOME and --destdir and it really looks like there's a bad interaction with setting both of them.

Sorry to bump this, but wondering if anyone took a look and see what's going on.

What seems to happen, is that since this patch added --destdir $GEM_HOME, bundler/setup cannot be found when required. In my use case, it's for standard bundle install imperative use when working on a ruby codebase. It seems to also affect bundlerEnv, at least according to #54303, where @immae found the same cause to the issue.

This seems to have been caused by how gems are installed into what looks like an incorrectly nested absolute path:

-result/lib/ruby/gems/2.5.0/gems/bundler-1.16.2
+result/lib/ruby/gems/2.5.0/nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/gems/2.5.0/nix/store/rwp5fpzqssf5m9dzbgbwsfgdzw8xajra-ruby-2.5.5/lib/ruby/gems/2.5.0/specifications/gems/bundler-1.16.2

Thanks very much — that gives me a much better place to start. I’ll look into this when I have a chance.