$ VAGRANT_LOG=[debug, info, warn, or error] vagrant up
These systems are broadly the same. If you're writing your configuration from scratch, they're all fairly pleasant, and it's mostly a matter of preference. They share most of the same concepts (although the terminology differs) and features. In my experience, their differences are primarily in feel and community.
For feel: Chef gives you Ruby pretending to be declarative. Puppet and Ansible give you something more declarative at the expense of some expressivity. Puppet has its own syntax, and Ansible shoe-horns some procedural aspects into YAML syntax. I prefer Chef here. (Chef also provides a web UI that lets you edit things, but I strongly advise against using it except for managing nodes. Everything else should be code/JSON.)
For community: With configuration management, one of the things you'll want is good community involvement. You don't want to write every cookbook/playbook/module from scratch. From what I've seen, Chef and Puppet have a large head start in this department.
That said, you should be prepared to customize the community offerings. People generally implement precisely what they need, in precisely the way they need it, and your needs will not always align. Fork all of the community offerings so you can modify them while still pulling from upstream. Managing this is decidedly difficult, but there's no better choice. It's one of the areas where git submodules would be really great, if only they were nicer to use. If you're going to use Chef, consider also using Berkshelf for managing your cookbooks.
If you do not have configuration management in place, pick one of the major ones, learn the hell out of it, and get to automating your operations. Having your infrastructure as code that you can run whenever you want, that you can review to see exactly how something is configured, is life changing. Once you get to doing it, you will never want to go back to the bad old days.
Based on my exposure, Chef ultimately boils down to being a complex remote execution framework. Puppet makes detect-and-correct more central to its model.
http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reign...
Appeals to authority don't tell us anything about the technology except that somebody we've heard of is using it.
In any case, noting Opsworks is based on Chef is not an "appeal to authority".[1] That knowing Chef means you have a head start on AWS's official devops tooling, seems a relevant data point for a comparison. (The officially supported devops tooling leveraging a particular CM system is different from simply being able to be managed by a CM system.)
As for Rackspace, here's the CM category of their dev blog:
http://developer.rackspace.com/blog/categories/configuration-management/
http://developer.rackspace.com/blog/cooking-with-chef4.html
The Rackspace Private Cloud Certification team sought out and tested a number of bare metal provisioning tools. While there are a number of excellent tools on the market, none seemed to fit quite well. On one hand, some tools were all-encompassing in scope and would try to provide an end-to-end solution. On the other hand, tools were too narrow in scope and provided a solution for a specific operating system or did not provide an appropriate amount of flexibility.
Eventually, we picked a deployment model consisting of a combination of tools that would provide the right balance of features and flexibility. We chose the Razor provisioning engine, combined with the OpsCode Chef configuration management tool.
Also, if you use port forwarding for all your databases etc. then you could technically just run Python code on your host computer. Indeed, I do this myself usually -- I treat the Vagrant box more like a "deployment target" that just happens to also run the DBs I can use for local testing.
Most of my python work isn't webdev so I've never had an issue with it in python but other daemons that do this sort of thing -- Brunch for example -- have given me intermittent trouble. I never did figure it out.
Keeping the long story short - it's a configuration management system. Have a look at http://www.opscode.com/chef/
Though it caused some kicking & screaming on the development team, the end result is that every developer has the same development environment, which pretty much matches our deployment environment (in Rackspace Cloud). I also just kicked off our summer intern class, and the interns were able to get productive with our codebase in 1 day despite not having much experience with modern Python web development, because pretty much every local setup step was automated.
I consider the tool invaluable. I don't even install any databases or tools directly on my laptop any longer. With its handy port forwarding feature, you can put all your DBs on a VM, yet still connect w/ CLI clients via your host machine. Then when you do "vagrant halt", all your DBs shut down at once and you free all those resources / memory / etc.
Also, one suggestion -- look into the debug logging level that you can set with an environmental variable. The only thing I found frustrating about Vagrant were situations where it would hang/fail but it wouldn't be clear why. It turns out their debug logging is quite good.