One of the biggest strengths for Vagrant is Chef (or Puppet if you prefer). Anything that requires "apt-get *" as part of your instructions after "vagrant up" and you're just doing it wrong.
Check your Vagrantfile and associated recipes into git. Then it's just "git clone; vagrant up"
The benefit of this is that you can share your stack by having someone else just git clone your stack. Rather than a blog post, we'd be looking at your chef recipe. I'd much prefer that.
Thanks for the feedback. I use Puppet too, but avoided it in the post to simplify it for the reader. Maybe I'll write a follow-up and include Puppet as well.
- If you're using bash to install dependencies, it might make sense to stick it in a shell file and run as a provisioner on `vagrant up` [1]
- You can set the NFS shared folder for your working directory to be anything you want in your Vagrantfile, eliminating cp'ing files. [2]
- `pip freeze` catches everything pip has installed, while you really only need Flask, virtualenv and gunicorn in your requirements. [3]
As people have said, Chef and Puppet will help with all of the above and the configuration of nginx, which is awesome. If you use a provisioner, when it comes time to deploy to an actual server, you'll have less manual work to do.
It also has the added benefit of heading towards dev-prod parity, something Vagrant can help with a lot.
I haven't used Vagrant, but in the past I did write a bunch of scripts using the Virtualbox CLI and puppet to automate creation of multiple virtual machines based on the contents of a few .ini files. Vagrant appears to tackle that same problem-- whether it's more effective or not I can't say. Though Vagrant is definitely more featureful than what I'd cobbled together, I'm not sure how much more valuable it would be to me personally. But having an organized, self-documenting, repeatable way to generate a serverlike infrastructure on your development machine can be very useful (if you don't have extra actual servers lying around to play with, anyway)
don't `apt-get install python-virtualenv` use `pip install virtualenv` because `pip` installs latest version, else you are under distro's package maintainer's mercy for update. After `python setup.py publish` only distro's package is updated.
EDIT: Using pip can simply solve py3 and py2 specific features.
There's an argument there - do you want to be at your distro's security update mercy, or have to remember/have two separate sets of security patch processes to run through?
My point was that DrCatbox was implying that Python as a language forces that user to jump through all of these hoops for deployment. This also implies that there are other languages where deployment is a moot point. Deployment is not a moot point just because there are services that will make it easy, and I wouldn't say that the existence (or not) of a service that makes deployment easy is a strength (or failing) or Python as a language. It's like saying that a hammer is lacking because no one has invented toolboxes yet.
Check your Vagrantfile and associated recipes into git. Then it's just "git clone; vagrant up"
The benefit of this is that you can share your stack by having someone else just git clone your stack. Rather than a blog post, we'd be looking at your chef recipe. I'd much prefer that.