[workhere-io]

Why use extra RAM on Vagrant when your Mac OS X is a full-featured Unix OS? Don't get me wrong, I know that the more complicated your setup gets, the more it would make sense to use Vagrant - but if you're just developing a CRUD Flask / Django app with PostgreSQL, you might as well just install Postgres.app and develop locally.

[taude]

I had tons of issues trying to get Postgres to work on my Mac. Lots of other conflicts, too. I think the Mountain Lion OS upgrade fried my host dev environment, too. Eventually, I went the VM route....afterall, you're going to eventually deploy to a Linux box anyway, and there's enough differences that you'll feel the pain when you go to deploy.

And now, I don't have a polluted host OS with tons of versions of software. I can easily try out new technologies, kill the VM, and start over.

Keeping VMs for different projects in their on silo'd around is really convenient.

Switching OSes or upgrading, rebuilding a computer, etc. I don't loose these configurations.

The list goes on and one.

RAM is cheap. I think I paid $100 to upgrade my Mac Book Pro to 16 GB.

I can also switch back to a host Windows machine and take my VMs with me (should the need arise)

[bluedino]

>> RAM is cheap. I think I paid $100 to upgrade my Mac Book Pro to 16 GB.

RAM was cheap. Prices have went up a lot. Most DDR3 prices have almost doubled since this past spring/winter. 16GB laptop kits are ~ $140 when they were $75 a few months back. Still relatively cheap, though.

Not to mention Apple only makes 1 laptop that you can add your own RAM to nowadays (13" MBP). It's $200 to go up to 16GB on a Retina.

[workhere-io]

I had tons of issues trying to get Postgres to work on my Mac

Did you try http://postgresapp.com ?

[taude]

Yes, I actually have that installed. Back when I was originally trying to get it to work, that wasn't available.

[koffiezet]

I prefer vagrant for most development projects for the simple reason that I can automate the VM + development environment generation AND commit it to a revision control system (git/svn).

Once set, I don't have to worry about re-installing my development environment - and can just let anyone check out my sources, who then has to do a simple "vagrant up", wait a few minutes, and he's up & running. No worrying about which things he specifically has to install and configure, my vagrant config takes care of that.

Also - the memory requirements are very limited imho, I run most of my vagrant Ubuntu 12.04 server VM's with with 128 or 256mb...

[Xylakant]

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.

[acdha]

> 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:

http://www.virtualenv.org/

> 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.

[Xylakant]

> 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.

> http://www.virtualenv.org/

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.

[kayoone]

yeah that works okay if you only need that, but then comes another project or new requirements and suddenly you run mongodb, redis and some background worker stuff as well and this slowly pollutes your system.

I did it that way for a long time too, but running vms became so convenient with vagrant and all the box configurations you can download that its kind of a no-brainer as long as you have 8Gigs of RAM or more.

[thejosh]

Because your settings won't always be the same as your production machine if you run a Mac?