How to for developers: Mastering your corporate MacBook Setup
#macos#development#tutorial#productivity
Nicoda-27

Nicoda-27 @nda_27

About: Software, Data, Python Engineering

Joined:
Feb 15, 2025

How to for developers: Mastering your corporate MacBook Setup

Publish Date: May 17
0 0

Starting with a fresh MacBook can be exciting, but navigating corporate IT requirements can feel daunting. This article demystifies the process, offering a step-by-step guide to ensure a smooth and efficient setup that aligns with your company's policies and empowers your productivity from day one.

This article will focus on a persona of a Python Developer but is transferable for any developers.

A corporate MacBook

Depending on your company, the Macbook provided to you as a developer workstation can pose certain difficulties when compared with a privately own MacBook.

Namely:

  • You will not be sudo of your workstation
  • A proxy could be implemented as company policy

Not being sudo will be the main difficulty and we will see how to navigate around that and still comply with your company policies, meaning we will not hack the system but leverage the MacOs potential.

Homebrew

Homebrew is the go to for developer using MacOs to be able to install applications. It's the equivalent of Aptitude in Ubuntu.

The official documentation requires you to be sudo to install it. But you can also install it for your specific user with

mkdir $HOME/homebrew && curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C homebrew
Enter fullscreen mode Exit fullscreen mode

This will create a directory Homebrew in your $HOME where brew will be installed.

You can now add it to your path permanently, in the rest of this article, it's assumed that zsh is your favorite shell (but feel free to use any other shells that you prefer)

echo 'export PATH=$HOME/homebrew/bin:$PATH' >> ~/.zshrc
Enter fullscreen mode Exit fullscreen mode

Let's check that Homebrew is detected and works:

The following command will make sure that the above export happened on your current terminal

source ~/.zshrc
Enter fullscreen mode Exit fullscreen mode

The following command should display a version, and proves that Homebrew was properly installed and is usable by your system.

brew --version
Enter fullscreen mode Exit fullscreen mode

Cli tools

Then let's give a try and install something

brew install git
Enter fullscreen mode Exit fullscreen mode

Now you are able to install all your favorite developer tools if packaged in Homebrew. They would appear for your user and you can install them without sudo permissions, yay !

Rich applications

Rich application will require an Applications directory for it to be installed; by default brew choose the /Applications directory which is located at the root of your file system and will not be accessible for you.

For instance, let's try to install OpenLens, it's a developer tool that showcase an UI to observe your Kubernetes cluster, it's proposed as a tool package in homebrew

If you try to install it with

brew install openlens
Enter fullscreen mode Exit fullscreen mode

This installation will fail because homebrew will not be able to use /Applications.

Instead, let's create our own Applications directory for our user.

mkdir $HOME/Applications
Enter fullscreen mode Exit fullscreen mode

Then you can leverage it when using Homebrew

brew install openlens --appdir $HOME/Applications
Enter fullscreen mode Exit fullscreen mode

You can now try to open OpenLens as an application from the Spotlight Search.

You can now install rich applications without sudo, yay !

Rosetta

There might be circonstances where you will need a specific target architecture for your application to run (namely either arm or intel).

The native architecture for M1, M2, M3, M4 MacBook is now arm, but Rosetta provides a way to emulate x86_64 architecture. It's very useful when librairies have been compiled for only one specific architecture, x86_64 being older there are higher chances to be available for this rather than for arm.

You can implement aliases to switch the Rosetta emulator on or off. You can add these two aliases to your .zshrc

alias arm="env /usr/bin/arch -arm64 /bin/zsh --login"
alias intel="env /usr/bin/arch -x86_64 /bin/zsh --login"
Enter fullscreen mode Exit fullscreen mode

To make sure of which target you are own, you can type

arch
Enter fullscreen mode Exit fullscreen mode

It should either displays i386 (x86_64/Intel architectures) or arm64 (arm/M* architectures

Installing language specific tools

To help you manage different versions of python, node, awscli, cargo the usage of mise will be demonstrated.

We will install two versions of mise so it can handle environments with both architecture as advised in here.

Just follow the installation guide above and should be able to have mise for x64 available with

mise-x64 --version
Enter fullscreen mode Exit fullscreen mode

And you can also have mise available for arm if you're sure you don't need x86_64 specifics.

Just follow the usual installation with Homebrew:

brew install mise
Enter fullscreen mode Exit fullscreen mode

You can now install python, node or many tools with mise.

The following command will install python for a specific x64_86 target:

mise-x64 use python@3.10
Enter fullscreen mode Exit fullscreen mode

Containerization tools

When we speak about containerization tool, there are multiple candidates.

The most used would be [docker](https://www.docker.com/- but open source alternatives like podman also exists.

Docker

You will need support of your IT team to be able to install docker as it requires sudo access.

Podman

It can act as docker but does not requires elevated privileges, you can easily install it with Homebrew or follow the guide:

brew install podman
Enter fullscreen mode Exit fullscreen mode

You can alias podman to docker to make it even more transparent. Add the alias in your .zshrc.

alias docker=podman
Enter fullscreen mode Exit fullscreen mode

As the podman cli is compliant with the docker cli, it should work transparently.

Give it a try:

docker run hello-world
Enter fullscreen mode Exit fullscreen mode

and it should be working. You will first have to run the following commands to initialise podman:

podman machine init
podman machine start
Enter fullscreen mode Exit fullscreen mode

There is a dedicated troubleshoot section to help you out.

Disclaimer:
Some tools like testcontainers relies entirely on pure docker therefore you will have issue using podman to replace it.

Though it can be solved thanks to podman-mac-helper but it requires elevated privileges from your IT team.

Proxy and certificates

Your company might put in place a proxy that is using a certificate.

When using python tools like az-cli, you will be blocked and stumble upon similar issues like this.

To solve it, as documented you will need to create an environment variables called REQUESTS_CA_BUNDLE to indicate the path to your certificate.

This is the case also when you will be installing dependencies and that a python tool requires internet access.

Finding the certificate

You will need to find the name of the certificate, so we can export it. To find the name, you can open Keychain Access application, on the certificates section, open the certificate added by your proxy team and copy the "Common name", let's assume the certificate is called "corporate_proxy_certificate".

security find-certificate -p -c "corporate_proxy_certificate" /Library/Keychains/System.keychain
Enter fullscreen mode Exit fullscreen mode

This should display the raw certificate value. If not you can look at other usual places for certificates, it can also be under /System/Library/Keychains/SystemRootCertificates.keychain.

Export the certificate

Now you can export it to a pem file like so:

security find-certificate -p -c "corporate_proxy_certificate" /Library/Keychains/System.keychain >$HOME/corporate_proxy_certificate.pem
Enter fullscreen mode Exit fullscreen mode

See the content of the .pem file with:

cat $HOME/corporate_proxy_certificate.pem
Enter fullscreen mode Exit fullscreen mode

Leverage the certificate

You can now export the environment variable and add it in the .zshrc

echo 'export REQUESTS_CA_BUNDLE=/$HOME/corporate_proxy_certificate.pem' >> ~/.zshrc
Enter fullscreen mode Exit fullscreen mode

And now, under the proxy any call to az cli tool should be working like a charm.

It also means that when disabling the proxy, you will need to unset the REQUESTS_CA_BUNDLE because it's part of your .zshrc like so:

unset REQUESTS_CA_BUNDLE
az login
Enter fullscreen mode Exit fullscreen mode

Conclusion

Hoping this article help navigating through corporate compliancy and still maintain high developer productivity.

Don't hesitate to reach out in comments if further explanation are necessary, or if there are missing topics.

Comments 0 total

    Add comment