Include local development environment without Vagrant

[alexgleason]

I think we need either:

1. Manual setup instructions without Vagrant, ie install postgres, make a virtualenv, etc, or:
2. A docker-based local dev environment like dev.sh

Otherwise @marykatefain won't be able to develop on this project since Vagrant requires virtualization and the T400 with libreboot has issues with virtualization.

[alexgleason]

Okay, so there's now updated instructions and a docker-compose.yml file for local development. The only issue involves pulling down the production database for local development. It needs Heroku Toolbelt to do that, which can't modify the local database without postgres client installed in the container. I'm not sure the pg:pull command even lets you specify a hostname (which would be necessary since we'd link the database container as db).

Part of me thinks, "let's just create a new image for Heroku Toolbelt + postgres client and push it to Docker Hub." Unfortunately I don't think we can when pg:pull still won't work: https://devcenter.heroku.com/articles/heroku-postgresql#pg-push-and-pg-pull It saves to a local DB, not letting us specify the DB's hostname or port.

We could use pg:backups to get a .dump file we can then import, but this still requires some scripting. dev.sh is looking more appealing now again. I guess we could use it in conjunction with docker-compose, but downloading two dependencies and then still needing to use a script seems a bit annoying. I wish docker-compose just shipped with Docker.

That said, docker-compose could be run in a container... I've done it before, but it requires mounting /var/run/docker.sock which might not work on non-Linux machines. It might also not be in the same place on different distros.

Basically we have these potentially mutually exclusive environments we want to enable painless local development for:

1. Linux users who can't use Vagrant because virtualization is not supported. Also, VirtualBox is considered non-free because it requires proprietary build tools.
2. MacOS and Windows users who might not be able to mount /var/run/docker.sock and have docker-compose work as expected.

The docker path is better, but we might just require people to install docker-compose and keep it updated, in conjunction with using a dev.sh type of script. Or just mount docker.sock for now and change it if anyone complains.