[ad_1]
TLDR: I’m conscious that there are many questions from folks making an attempt 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 thus far all goes properly. 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 immediately from https://brew.sh. I dumped my Brewfile on the previous 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 challenge. This additionally labored fully as anticipated with no hickups in any way, since all dependencies that rbenv or rbenv set up wanted had been already in my Brewfile.
I’ve copied nothing from the earlier MBP immediately. I’m 100% sure that there isn’t a confusion with some previous structure binary slipping onto the brand new machine. Nothing in /usr/native/bin has been copied. ~/.rbenv has not been copied.
To date so good. Sadly, it seems {that a} single gem that I would like for that challenge, and which has a requirement on a closed-source binary from a vendor, isn’t but obtainable for Apple Silicon. I can’t eliminate that gem, however utilizing it with the silicon model of ruby is simply not on the desk but.
Query
Whereas ready for the difficulty to resolve itself, my thought is that this: is it attainable 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 surroundings variables)? Luckily, I don’t require rbenv or ruby to be obtainable in each installations; I solely use it for that single challenge.
It will 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 surroundings can be lively, and the /choose/homebrew surroundings can be hidden (i.e., possibly take /choose/homebrew out of all $PATH and so forth. variables).
I’m conscious that the prolonged set up docs of brew describe the right way 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 properly (even when unsupported by brew, as said clearly)?
What would the required surroundings 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 isn’t in any variable? If I begin a bash with arch ..., does that structure alternative routinely get handed on to any subprocesses (i.e., when working brew, rbenv, and shims like ruby, cucumber and so forth.) or are there identified instances the place this setting by some means will get misplaced?
The rationale why I feel it will be finest to begin 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 few of the extra “intense” gems.
Bonus query
As talked about earlier than, I might settle for if the 2 brew environments are fully separate, and just one is ever “on” at any given time.
Would there be a option to have them each lively on the similar time (i.e. each within the PATH), possibly ensuring that the set up listing of the at the moment “lively” brew is first in PATH and different variables? Or is that this state of affairs positively out, as being a lot to dangerous?
[ad_2]