Avoid breaking gem extensions when aliased Ruby becomes versioned formula

[codiophile]

brew gist-logs <formula> link OR brew config AND brew doctor output

$ brew config
HOMEBREW_VERSION: 4.2.6
ORIGIN: https://github.com/Homebrew/brew
HEAD: cfac516ee045d869be34598152e80a11ef2befe7
Last commit: 4 days ago
Core tap JSON: 31 Jan 15:24 UTC
Core cask tap JSON: 31 Jan 15:24 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: ["--no-quarantine"]
HOMEBREW_CLEANUP_PERIODIC_FULL_DAYS: 3650
HOMEBREW_MAKE_JOBS: 4
HOMEBREW_NO_AUTO_UPDATE: set
Homebrew Ruby: 3.1.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: quad-core 64-bit dunno
Clang: 15.0.0 build 1500
Git: 2.43.0 => /opt/homebrew/bin/git
Curl: 8.4.0 => /usr/bin/curl
macOS: 14.2.1-arm64
CLT: 15.1.0.0.1.1700200546
Xcode: 15.1
Rosetta 2: false

$ brew doctor
Your system is ready to brew.

Verification

• My "brew doctor output" says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

Install [email protected]

What happened (include all command output)?

It installed, but didn't create all the required symlinks. Only:

lrwxr-xr-x 1 admin admin 24 Jan 31 15:29 [email protected] -> ../Cellar/[email protected]/3.2.3

What did you expect to happen?

That it would create all required symlinks, as it did for 3.2.2:

lrwxr-xr-x 1 admin admin 22 Jan 4 17:53 ruby -> ../Cellar/ruby/3.2.2_1
lrwxr-xr-x 1 admin admin 22 Jan 4 17:53 ruby@3 -> ../Cellar/ruby/3.2.2_1
lrwxr-xr-x 1 admin admin 22 Jan 4 17:53 [email protected] -> ../Cellar/ruby/3.2.2_1

Step-by-step reproduction instructions (by running brew commands)

brew install [email protected]

# You can then verify the symlinks using:
ls -al /opt/homebrew/opt/ruby*

[Bo98]

Because Ruby 3.3 exists now.

brew install ruby and brew install ruby@3 always point to the latest. If you're wanting to pin to a specific minor version you're wanting [email protected] anyway.

[codiophile]

Because Ruby 3.3 exists now.

brew install ruby and brew install ruby@3 always point to the latest. If you're wanting to pin to a specific minor version you're wanting [email protected] anyway.

Thank you @Bo98! That explains why. The reason I found this is that our Fastlane scripts broke after the update. Apparently /Users/admin/.bundle/ruby/3.2.0/gems/date-3.3.4/lib/date_core.bundle is trying to load /opt/homebrew/opt/ruby/lib/libruby.3.2.dylib. It seems unlikely that it would be hardcoded to look for the library in the ARM homebrew directory. It seems more likely that the Ruby installation is misconfigured in some way and that's the actual bug.

[Bo98]

Thanks for the context. There's probably somewhere in the RbConfig that's pointing to opt/ruby that should instead point to opt/[email protected] - I'll have a poke around.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[cho-m]

There's probably somewhere in the RbConfig that's pointing to opt/ruby that should instead point to opt/[email protected]

I think it is just from the install name, which is used when linking .bundle.

[Bo98]

Hmm yeah, that makes sense. Might be worthing seeing if it makes sense to change the install name to be opt/[email protected]

[cho-m]

Hmm yeah, that makes sense. Might be worthing seeing if it makes sense to change the install name to be opt/[email protected]

If we want to support scenario of user installing via alias (e.g. brew install [email protected]) with expectation of dynamic linkage working when brew upgrade changes to next major/minor (e.g. 3.4), then it would either require install name modifications or versioning all ruby formulae.

Not sure if there is any use case of the unversioned symlink (i.e. libruby.dylib). I don't think it will be used.

Assuming Ruby expects major/minor API versioned libs/paths, then we can explore one of above approaches.

---

EDIT:
One inconvenience for install name change is that it will need to be done during post-install. brew relocation automatically overwrites change if done during install. This results in some extra permission modifications and re-codesigning steps.

In case of swapping formula and alias, the limitation is when we just want the latest/linked copy as we don't allow depending on an alias. For Linux, uses_from_macos "ruby" may work, but it is possible that we will migrate macOS dependency to use brew ruby given Apple's own deprecation/removal plans.