Closed SMillerDev closed 1 year ago
@Bo98 ?
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.
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).
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.
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.
Something that can be done now is enabling
brew
CI to run on Ruby 3 (usingruby/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?
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.
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.
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.
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.
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
.
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.
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.
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
.
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.
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?
Sure, in terms of that yeah. Though I imagine there'll be some steps in between opt-in/CI and enabling for everyone?
This should allow the build for ARM to succeed at least.