Ansible on Mac OSX: Pip vs Homebrew Installation Best Practices for Python DevOps


2 views

When setting up Ansible on Mac OSX Mavericks, you're faced with two primary installation paths - Python pip and Homebrew. Both methods will get Ansible running, but the choice impacts your development workflow and system maintenance.

The pip method provides direct installation from Python Package Index:

# Install via pip
sudo pip install ansible

# Verify installation
ansible --version

Pros:

  • Gets the latest Ansible version directly from PyPI
  • Works well in Python virtual environments
  • Easier to manage alongside other Python dependencies

Cons:

  • Potential conflicts with system Python
  • Requires manual updates
  • No automatic dependency resolution for system packages

Homebrew provides a more system-integrated approach:

# Install via Homebrew
brew install ansible

# Verify installation
ansible --version

Pros:

  • Better integration with OSX system
  • Automatic dependency management
  • Easier version management with brew upgrade

Cons:

  • Might lag behind PyPI releases
  • Potential PATH conflicts (as you've encountered)
  • Less flexible for Python-specific environments

The warning about /usr/bin occurring before /usr/local/bin indicates a common issue. Here's how to fix it:

# Add Homebrew to your PATH priority
echo 'export PATH="/usr/local/bin:$PATH"' >> ~/.bash_profile
source ~/.bash_profile

For Vagrant-based development environments, I recommend:

  1. Use Homebrew for system-wide Ansible installation
  2. Create Python virtual environments for project-specific Ansible needs
  3. Manage dependencies through requirements.txt when needed
# Example workflow
brew install ansible
python -m venv myproject
source myproject/bin/activate
pip install -r requirements.txt

If you need multiple Ansible versions, consider these approaches:

# Using pip for version-specific installation
pip install ansible==2.9.0

# Using Homebrew for version pinning
brew install ansible@2.8

Remember to check your current installation method before making changes:

# Check installation source
which ansible
head -n 1 $(which ansible)

When setting up Ansible on Mac OSX Mavericks, the primary decision point comes down to two package management systems:

  • Python's pip (package installer for Python)
  • Homebrew (macOS package manager)

Let's examine the technical implementations:

# Pip installation
$ sudo pip install ansible

# Homebrew installation
$ brew install ansible

The pip method installs Ansible directly into Python's site-packages, while Homebrew maintains its own cellar structure at /usr/local/Cellar/ansible.

The warning you encountered about /usr/bin occurring before /usr/local/bin is critical. Here's how to diagnose:

$ echo $PATH
$ which ansible
$ ansible --version

This path conflict can lead to version mismatches when both pip and Homebrew installations exist.

Ansible's core dependencies differ between installation methods:

Dependency Pip Version Homebrew Version
Python 2.7+ or 3.5+ Python 3 (via brew)
Paramiko Bundled Separate formula
SSH System Brew's openssh

For Vagrant integration, consider these Ansible provisioner examples:

# Pip-based provisioning
config.vm.provision "ansible" do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.verbose = "vv"
end

# Homebrew-specific path reference
config.vm.provision "ansible_local" do |ansible|
  ansible.playbook = "playbook.yml"
  ansible.install_mode = "pip"
end

After extensive testing on Mavericks, I recommend:

  1. Uninstall existing pip installation: pip uninstall ansible
  2. Clean up residual files: rm -rf ~/.ansible
  3. Install via Homebrew: brew install ansible
  4. Verify path precedence: brew doctor

This approach provides better dependency isolation and easier future upgrades through brew upgrade ansible.

If encountering SSH connectivity problems:

# For pip installations
$ pip install --upgrade paramiko

# For Homebrew installations
$ brew reinstall ansible
$ ansible all -i "localhost," -m ping

Remember to check your ansible.cfg for any path-specific configurations that might need adjustment after switching installation methods.