Because even though OS X is a pretty full-featured unix not all software that installs easily on a linux installs easily on a mac os. Vagrant boxes also are platform independent if he had a vagrant development env, he wouldn't have to blog about how to install python. You also can get closer to the target env - i.e. use the python you'll have on the target server etc. You certainly can install all pythons that your projects use side-by-side, but this quickly turns into a mess when you have multiple projects that deploy on different target systems, maybe with different sets of libraries etc. You can test/develop deployment scripts locally. All in all: It's cleaner, less work and more flexible. In general the extra ram is not relevant now that the upgrade from 8G to 16G costs a mere 200 EUR.
> Because even though OS X is a pretty full-featured unix not all software that installs easily on a linux installs easily on a mac os
Having used Homebrew now for many years, this is really just lingering FUD from many years ago. I've spent at least as much time building custom RPM/DEB packages, finding PPAs, etc. for things which don't compile cleanly on a particular Linux distribution. That's just a cost of using bleeding-edge or obscure packages: the right lesson to draw is to avoid taking on the cost of using less stable packages unless you gain significant benefit.
> Vagrant boxes also are platform independent if he had a vagrant development env, he wouldn't have to blog about how to install python
He didn't — that's a local cost he chose to take on for perceived benefits but it's neither necessary not advisable if you don't need something other than the system installed Python (2.5-2.7). This is exactly the same situation as on a Linux distribution.
> You certainly can install all pythons that your projects use side-by-side, but this quickly turns into a mess when you have multiple projects that deploy on different target systems, maybe with different sets of libraries etc.
This is a platform-neutral problem which has been well solved for many years using Virtualenv:
> All in all: It's cleaner, less work and more flexible.
What you described is a LOT more work and adds significant performance and usability overhead to things you do many times a day, particularly if you need to work on more than one project and spend time spinning Vagrant instances up and down, installing updates, etc. rather than doing something productive.
It might still be worth it if you really need to test your deployment process all the time but otherwise that cost adds up. Personally, running locally and testing on EC2 has been much easier, faster, and makes my testing realistic by using the actual real production infrastructure rather than a facsimile crammed onto one laptop.
> Having used Homebrew now for many years, this is really just lingering FUD from many years ago.
Actually, I can cite an example. Try installing libmediainfo on your mac. It's a pita that requires hacking the makefiles in obscure ways. Even after hacking the makefile it installs in different locations than on linux, making all software that depends on it more difficult to compile. Oh, and yes, there's a gui package but it doesn't contain the required library files and headers.
Homebrew is fine for everything that homebrew packages exist for. Anything else you'd better hope that the authors provided a working makefile or be prepared to learn how to fix it.
> spend time spinning Vagrant instances up and down, installing updates, etc. rather than doing something productive.
I install updates when the target env installs updates. I share the puppet/chef files that are used to update the target env - so the maximum amount of time I spend doing unproductive things is typing "vagrant up" in the morning and "vagrant suspend" in the evening. Each one of those commands runs 30 seconds.
Since when does virtualenv install the actual pythons?
> Personally, running locally and testing on EC2 has been much easier
You're certainly aware that you can use packer and vagrant in combination to build the same box for virtualbox/vmware for local use and as an AMI for use in EC2, making your development env a clone of the production env? Just with faster connectivity and no need to be online for work? Vagrant can even spin that ec2 instance up and down for you.
