Rubygem conflicts with Ruby packages

Help
1

I currently have 2 ruby packages installed, cocoapods and jazzy, and both use the same claide-1.0.2 gem. Since it seems rubygems must be symlinked into ~/.nix-profile/lib/ruby/gems/2.5.0/gems, trying to install both cocoapods and jazzy produces a conflict on the claide gem, requiring me to set a priority on one of these packages.

First off, I’m actually kind of surprised ruby packages don’t get wrapped up in some sort of script that redirects the rubygems directory at the per-package lib folder, such that the gems don’t need to be linked into the profile. But ignoring that for a second, I’m left with 2 questions about this process:

  1. Looking into it, both jazzy and cocoapods use the exact same derivation for claide-1.0.2. The way the packages work, they each re-specify the definition of claide, but the definitions are the same so they end up at the same store path. This means both jazzy and cocoapods actually have lib/ruby/gems/2.5.0/gems/claide-1.0.2 as symlinks to the same store path (/nix/store/haq9z019vwq1q2n1diqqqn95b3v7k2y6-ruby2.5.5-claide-1.0.2/lib/ruby/gems/2.5.0/gems/claide-1.0.2). Given that they’re the exact same path, I’m kind of surprised there’s a conflict at all upon installation, though I guess the install process doesn’t care that this path is a symlink (even though the nix store is read-only so it could absolutely indirect through symlinks if it wanted to without worrying about the files changing).
  2. Looking at my nix profile gems, some of the gems are symlinked entirely (such as .nix-profile/lib/ruby/gems/2.5.0/gems/ffi-1.10.0) and some are directory trees where every file in the tree is a separate symlink (such as .nix-profile/lib/ruby/gems/2.5.0/gems/escape-0.0.4). It’s not clear to me why this is, or if that even matters.

I’m also wondering if there’s any solution here beyond setting unique priorities on the ruby packages I want to install that have overlapping gems.

2

Presumably both cocoapods and jazzy are supposed to be only executables. Yet they’re using bundlerEnv, and thus expose way too many internals and can cause conflicts. It’s better to package them with bundlerApp instead so only the executables will be in the profile.

I’ll make some PRs for this, unfortunately it’s rather common that people don’t know the difference and end up with conflicts (esp. around common executable names of dependencies like bundler, setup, or console.

2 Likes
3

Ah hah, that would definitely explain the conflict. I didn’t realize there were 2 separate ways of doing Ruby packages. I’ve got open PRs for both packages right now, so I’ll check out bundlerApp and update my PRs to use that tomorrow.

4

Thanks, that’d save me some work, please mention me on the PRs or link them here so I can review them :slight_smile:

5

The two PRs are

I haven’t updated them to bundlerApp yet but I’m going to go test that right now.

1 Like
6

I’ve now updated them. Switching to bundlerApp was pretty trivial, though I did include a commit on the cocoapods PR to make the gemdir parameter optional like it is for bundlerEnv.