[ad_1]
TLDR: I’m conscious that there are many questions from individuals attempting emigrate from Intel to Apple Silicon installations of homebrew; and plenty of questions that talk of confusions from undesirable conflicts between these. This isn’t about that. That is about working two installations facet by facet and avoiding any mixing or involuntary confusion between the architectures.
Background
I’m organising a model new 2024 MBP, and to this point all goes effectively. I’m coming from an Intel MBP. I’ve put in brew (on the brand new machine) from scratch, absolutely native, with the evil “curl” methodology instantly from https://brew.sh. I dumped my Brewfile on the outdated machine, and put in all of the packages I had on the brand new, from that. This efficiently pulled all of the native variations of the packages and put in them in /choose/homebrew as marketed.
I additionally used rbenv, put in by way of brew, to construct some model of ruby that I would like for a undertaking. This additionally labored fully as anticipated with no hickups by any means, since all dependencies that rbenv or rbenv set up wanted had been already in my Brewfile.
I’ve copied nothing from the earlier MBP instantly. I’m 100% sure that there isn’t any confusion with some outdated structure binary slipping onto the brand new machine. Nothing in /usr/native/bin has been copied. ~/.rbenv has not been copied.
To this point so good. Sadly, it seems {that a} single gem that I would like for that undertaking, and which has a requirement on a closed-source binary from a vendor, will not be but out there for Apple Silicon. I can’t do away with that gem, however utilizing it with the silicon model of ruby is simply not on the desk but.
Query
Whereas ready for the problem to resolve itself, my thought is that this: is it potential to put in an Intel structure model of brew (and subsequent instruments like rbenv and the shims offered by it) in /usr/native/bin which is fully separate from the Apple Silicon model in /choose/homebrew, and which is by default additionally disabled (by advantage of the trail not being in any atmosphere variables)? Luckily, I don’t require rbenv or ruby to be out there in each installations; I solely use it for that single undertaking.
It might possibly be cleanest to have a script that I can supply in a bash which units a bunch of variables, and from then on, in that exact course of, the /usr/native/bin atmosphere could be energetic, and the /choose/homebrew atmosphere could be hidden (i.e., possibly take /choose/homebrew out of all $PATH and many others. variables).
I’m conscious that the prolonged set up docs of brew describe learn how to set up a number of variations in arbitrary directories. I couldn’t discover any point out of my utilization state of affairs within the documentation or the brew github points although. Am I setting myself up for catastrophe, or is that this identified to presumably work effectively (even when unsupported by brew, as said clearly)?
What would the required atmosphere variables? Is it sufficient to simply prefix any bash or different command I intend to run with the Intel variations with arch -x86_64 ... and ensure /choose/homebrew will not be in any variable? If I begin a bash with arch ..., does that structure selection mechanically get handed on to any subprocesses (i.e., when working brew, rbenv, and shims like ruby, cucumber and many others.) or are there identified instances the place this setting by some means will get misplaced?
The rationale why I believe it could be greatest to start out with brew and never solely arch’ify rbenv itself is that there are a couple of dependencies that rbenv must compile ruby, and these are simple to put in with brew. Therefore I might keep away from having to fully manually set up any dependencies of rbenv, ruby or a number of the extra “intense” gems.
Bonus query
As talked about earlier than, I’d settle for if the 2 brew environments are fully separate, and just one is ever “on” at any given time.
Would there be a approach to have them each energetic on the similar time (i.e. each within the PATH), possibly ensuring that the set up listing of the at the moment “energetic” brew is first in PATH and different variables? Or is that this state of affairs undoubtedly out, as being a lot to dangerous?
[ad_2]