Setting up Dev Env on M1 Pro

Update 22/11/05

Using Homebrew works for most apps without needing Rosetta. Now I completely manage through homebrew again. Tools I use are now…

• Oh my zsh
• Homebrew
• Font: Pragmata Pro Liga

Under homebrew

• fig
• asdf (python only works on 3.7.13, 3.8.13, 3.9.11 and 3.10.3)
• visual-studio-code
• docker (for running dbs. enable docker compose in preferences.) https://www.code4it.dev/blog/run-mongodb-on-docker
• tableplus
• spotify
• iterm2
• google-chrome
• 1password
• devutils
• cleanmymac
• discord
• k9s
• numi
• paw
• google-cloud-sdk (with kubectl installed under components)

To use kubectl as gcloud component, add this to .zshrc

export PATH=”`brew — prefix`/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin:$PATH”`

Will update Visual Studio Code plugins in the future.

Update 22/08/15

VM environment on M1 turned out to be too unstable so I reverted back to installing apps natively and making use of homebrew only for packages (not casks). Some other things I adopted…

• oh my zsh + spaceship
• using hotkey on iterm2
• using lsd / pls for prettier ls… still figuring out which is better. I don’t recommend exa as documentation and binaries don’t seem to get updated well.
• Fig for autocompletion and recommendations on terminal

Migration during setup is not recommended, especially if Virtualbox or other VM related things were installed

I’ve introduced how setting up disposable development environment makes for a clean workspace in the last post, but there is one caveat — it won’t work on M1, at least not verbatim.

I thought of three possible ways to approach my set up, and to stick to one of them.

1. Install everything through distributed image files from official websites or App Store
2. Use homebrew for M1 exclusively
3. Use homebrew for x86 exclusively

This idea of sticking to one particular way of doing things actually came from this video on TDD, and one of its takeaways is not to mix mock with real data while testing. Like how test codes break at random times because of conflicting ideas about what conditions tests should cover, there will be conflicts in different approaches taken in a laptop setup — and unless you’re a hardware or software interface guru, debugging this conflict can be time-consuming.

After some trial and error, I figured it’s best to ditch using homebrew for good. The disposable environment idea provides for a minimal number of apps to be run on the host machine, after all, so it is not too hard to manage the apps.

I followed through the guide above word by word, installing everything as recommended by the provided distribution images. Then configured Vagrantfile.

Vagrant.configure("2") do |config|
  config.vm.box = "spox/ubuntu-arm"
  config.vm.box_version = "1.0.0"
  config.vm.hostname = "rusty-spoon"
  config.vm.define "rusty-spoon"
  config.vm.provider "vmware_desktop" do |v|
    # v.gui = true
    v.memory = "2048"
    v.linked_clone = false
    v.vmx["ethernet0.pcislotnumber"] = "160"
  end
end

There are few things to note about this setup

• Unlike Virtualbox, you can’t setup a fixed private network IP on VMware. This is a known issue on Vagrant documentation. According to the gist thread above, some people have made it work, albeit unstable.
• Occasionally you may run into some errors about vagrant vmware utility when you run vagrant up . This is most likely a temporary error; waiting a bit, restarting terminal / vmware etc and trying it again will work again.
• Running vagrant up while connected to a hotspot may not work. I had no issue with Wifi networks, but running it after connecting to hotspot network on iPhone did not work (hangs on “Waiting for the VM to receive an address…” or some other process).

All I have on host machine is now…

• VMware Fusion Tech Review
• Visual Studio Code
• 1password
• TablePlus
• DevUtils
• IINA