Use Tapioca with >=Ruby 2.7 for generating RBI files

[MikeMcQuaid]

Provide a detailed description of the proposed feature

Tapioca, which we use with brew typecheck --update, has removed support for Ruby 2.6, which we use for Homebrew.

Our tapioca/"Update RBI files" CI job should be updated to always use a system, GitHub Actions Ruby >=2.7.

Our brew typecheck --update usage outside of CI, i.e. for maintainers/contributors, should use whatever version brew install ruby installs.

What is the motivation for the feature?

Be able to update the Tapioca gem in Homebrew/brew.

How will the feature be relevant to at least 90% of Homebrew users?

Fewer bugs due to better RBI files and type checking.

What alternatives to the feature have been considered?

• ask Tapioca team to reconsider (already tried)
• do nothing and accept we're staying on an old version indefinitely
• make all of Homebrew use a newer Ruby version requiring portable Ruby on latest macOS versions rather than using the system Ruby

[Bo98]

I can look into this, but I'll probably wait and see if macOS 13 beta 1 in three weeks is going to force a Ruby change on us (or if we otherwise decide then to just drop system Ruby).

It's also worth noting there's a few gems already with Ruby 2.7 requirements.

[MikeMcQuaid]

I can look into this, but I'll probably wait and see if macOS 13 beta 1 in three weeks is going to force a Ruby change on us (or if we otherwise decide then to just drop system Ruby).

For anyone watching: it didn't and we don't want to drop system Ruby yet.

[Bo98]

So we've got two options really:

• Split the dependencies in half for two different Ruby versions.
• Allow brew as whole to run (potentially via env) under newer Ruby (e.g. 3.1). While not necessary for things like Tapioca which run external, it might simplify some dependency management and trying to align things between two lock files (e.g. Sorbet Runtime).

[MikeMcQuaid]

• While not necessary for things like Tapioca which run external

Given this: could we not just run purely Tapioca under 3.1 and nothing else without any splitting?

[Bo98]

Tapioca needs sorbet-runtime, Homebrew needs sorbet-runtime for HOMEBREW_SORBET_RUNTIME (in all cases eventually when we get rid of sorbet-runtime-stub). These versions should be synced.

[MikeMcQuaid]

These versions should be synced.

Should be or must be?

[Bo98]

If Sorbet makes a backwards-incompatible change like in #13164: must.

Otherwise you can probably get away with it.

[MikeMcQuaid]

@Bo98 I reckon we try to get away with it for now? Thoughts?

[Bo98]

Probably - I can have a look. What's the plan with #13309?

[MikeMcQuaid]

@Bo98 Thanks! Unsure. I thought the goal there was for testing later versions but I'm not sure that's actually what's implemented there. I'm fine with a developer-only flag to allow testing with a newer Ruby but don't want it to ever be a requirement for developers or end-users to use a non-system Ruby on newest macOS until it goes away.

[Bo98]

I mainly asked because #13309 implied allowing Homebrew to work under a newer Ruby which can overlap with this as it doesn't make sense special casing Tapioca if we plan to go ahead with #13309 (+ fixes to actually make it work under newer versions of Ruby).

[MikeMcQuaid]

@Bo98 Personally, I don't think there's any value in running Homebrew under a newer Ruby beyond "testing for a impending new macOS system Ruby version".

[Bo98]

In that case it would make sense if #13309 targeted a specific secondary version of Ruby, of which is not yet known given there's no impending new macOS system Ruby version, rather than a blanket anything newer.

[dduugg]

Is this still something we wan to pursue? I'd like to give it a shot if so.

[Bo98]

A bit has changed in a year.

I'd say it's increased in scope since then in that I reckon we might end up using a newer Ruby for most dev stuff. Non-devs are still in limbo a bit and there's no clear consensus - maybe it'll be clearer when macOS 14 beta is released on 5th June though I also thought that last year.

I was asked on Slack what a Portable Ruby 3 would look like so I can get a branch for that this weekend. I can also add Ruby 3.2 to CI here if we want since everything except vendored gems should already work.

One thing's for sure: Sorbet will need updating for macOS 14, and it will not support Ruby 2.6.

[MikeMcQuaid]

I'd say it's increased in scope since then in that I reckon we might end up using a newer Ruby for most dev stuff. Non-devs are still in limbo a bit and there's no clear consensus - maybe it'll be clearer when macOS 14 beta is released on 5th June though I also thought that last year.

Given the lack of new information to the contrary we should plan for:

• using Ruby >=2.7 but only require on these gems for for Homebrew's dev-cmd (much as we never require non-dev-cmd to run bundle install and instead vendor the runtime gems). Note: this also restricts our usage of gems with native extensions to dev-cmd, too.
• continue using the system Ruby 2.6 on the newest version(s) of macOS

[MikeMcQuaid]

Work in underway to move to Ruby 3 and this issue will be resolved then so: closing.