search

Homebrew / homebrew-portable-ruby

🚗 Versions of Ruby that can be installed and run from anywhere on the filesystem.
BSD 2-Clause "Simplified" License
129 stars 42 forks source link

allow test to run for ruby3 branch #173

Closed SMillerDev closed 1 year ago

SMillerDev commented 1 year ago

This should allow the build for ARM to succeed at least.

SMillerDev commented 1 year ago

@Bo98 ?

Bo98 commented 1 year ago

Sorry, didn't see this!

This is fine, though I consider Portable Ruby 3 pretty much dead for now given the desire to stay on 2.6 for as long as Apple ship it (which could be years for all we know - Apple have a lot of internal stuff using it to deal with - and we're included in that AFAIK as unlike before where we supported 2.3, 2.4, 2.5 and 2.6 at the same time, we don't do that anymore). I guess we'll see in a month's time if there's any signs for this year.

I'd also like to not force users to have to bundle install, but this is fine as a temp fix for this branch only given it's still undecided how we'll handle that.

As for dev-cmd cases: I don't know yet. From discussions so far, there's a desire to not use Portable Ruby (we are able to install two versions side-by-side if we wanted), but using homebrew-core's Ruby has the potential to break < Big Sur (or at least make it really slow as we've enabled features in homebrew-core's Ruby that now needs to build Rust etc). Some third-party taps do support older macOS, and that has always been ok with us! So I'm still trying to figure out something there that'll work for everyone.

MikeMcQuaid commented 1 year ago

This is fine, though I consider Portable Ruby 3 pretty much dead for now given the desire to stay on 2.6 for as long as Apple ship it

To be clear: given recent discussions I now consider this to no longer apply and it to be fine to move to Portable Ruby 3 ASAP (or at least: for Sonoma's GA).

Bo98 commented 1 year ago

Yeah this is on the cards to revisiting shortly.

Something that can be done now is enabling brew CI to run on Ruby 3 (using ruby/setup-ruby). I can open a PR for that. Eventually that will switch to Portable Ruby of course, but adjusting CI now could help us make sure we're not introducing regressions in between the times I've been testing on Ruby 3, which is only every so often. We can also wait though for Portable Ruby - I don't mind either way.

Bo98 commented 1 year ago

I'll rebase and tidy up the ruby3 branch shortly and see where things are at. There's one patch I will also look at upstreaming, though I don't consider that a blocker.

MikeMcQuaid commented 1 year ago

Something that can be done now is enabling brew CI to run on Ruby 3 (using ruby/setup-ruby). I can open a PR for that. Eventually that will switch to Portable Ruby of course, but adjusting CI now could help us make sure we're not introducing regressions in between the times I've been testing on Ruby 3, which is only every so often. We can also wait though for Portable Ruby - I don't mind either way.

Works for me 👍🏻

We should probably keep at least one basic test on Ruby 2 for now. Perhaps we could switch only Linux over to Ruby 3 for now and use Ruby 2 for macOS until we ship portable Ruby there?

MikeMcQuaid commented 1 year ago

There's one patch I will also look at upstreaming, though I don't consider that a blocker.

Would like to block on it being submitted upstream before we release portable Ruby but don't think it needs merged.

Bo98 commented 1 year ago

There's one patch I will also look at upstreaming, though I don't consider that a blocker.

Would like to block on it being submitted upstream before we release portable Ruby but don't think it needs merged.

Yeah sorry, should have clarified it that way.

Bo98 commented 1 year ago

We should probably keep at least one basic test on Ruby 2 for now. Perhaps we could switch only Linux over to Ruby 3 for now and use Ruby 2 for macOS until we ship portable Ruby there?

Yeah was thinking a matrix of Ruby 3 and Ruby 2 of course - absolutely not a complete switch to Ruby 3 yet.

Bo98 commented 1 year ago

Are we game to start vendoring Ruby 3 gems now? That's the main issue right now as you cannot run brew without basic gems like activesupport installed.

MikeMcQuaid commented 1 year ago

Yeah was thinking a matrix of Ruby 3 and Ruby 2 of course - absolutely not a complete switch to Ruby 3 yet.

Sounds good 👍🏻.

Are we game to start vendoring Ruby 3 gems now? That's the main issue right now as you cannot run brew without basic gems like activesupport installed.

I'd like to avoid vendoring more than one version in the repository. For now, it should be expected you'll need to run brew install-bundler-gems manually or automatically to install the relevant gems which should be hidden by .gitignore.

Bo98 commented 1 year ago

For now, it should be expected you'll need to run brew install-bundler-gems

Except you can't because these things get required before you even reach CLI parsing. Bit of a chicken egg problem right now, unless we move the whole thing to a plain Ruby script that gets invoked from shell.

Bo98 commented 1 year ago

There's symlink magic we could also do but I'll need to try that out in practice beforehand.

I think for now we won't do separate Ruby 2 and Ruby 3 lockfiles, so the versions for the two Ruby versions should be identical (except binary differences in native extensions). We'll continue to lock everything based on Ruby 2.6 as we are currently until we've fully switched as it just makes everything so much simpler and I think we're expecting to fully switch fairly soon anyway? Then we will update everything.

MikeMcQuaid commented 1 year ago

Except you can't because these things get required before you even reach CLI parsing. Bit of a chicken egg problem right now, unless we move the whole thing to a plain Ruby script that gets invoked from shell.

I think it could be moved to Bash, honestly, as it's essentially just doing bundle check && bundle install. This could be as a separate brew install-bundler-gems-bash hidden command at first if we wanted to maintain all the existing easier-in-Ruby behaviours.

The logic is straightforward for the vendored gems (which don't have native components), though: if they are missing, cd Library/Homebrew && bundle install.

Bo98 commented 1 year ago

The logic is straightforward for the vendored gems (which don't have native components), though: if they are missing, cd Library/Homebrew && bundle install.

Not quite - or at least not yet. What I will do is separate all non-vendored gems into groups which would make it so that will only do vendored gems and no native stuff.

MikeMcQuaid commented 1 year ago

The logic is straightforward for the vendored gems (which don't have native components), though: if they are missing, cd Library/Homebrew && bundle install.

Not quite - or at least not yet. What I will do is separate all non-vendored gems into groups which would make it so that will only do vendored gems and no native stuff.

I think that's a "nice to have". For now when Ruby 3 is only being used by developers/in CI (which I expect to be the case until we move everyone to Portable Ruby 3): doing a plain bundle install really should be sufficient, no?

Bo98 commented 1 year ago

Sure, in terms of that yeah. Though I imagine there'll be some steps in between opt-in/CI and enabling for everyone?