Merge pull request #835 from aanand/rebrand

Rebrand (pre-RC)

Author: aanand

.gitignore

@@ -5,4 +5,4 @@
 /dist
 /docs/_site
 /venv
-fig.spec
+docker-compose.spec

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to Fig
+# Contributing to Compose
 
 ## TL;DR
 
@@ -11,14 +11,14 @@ Pull requests will need:
 
 ## Development environment
 
-If you're looking contribute to [Fig](http://www.fig.sh/)
+If you're looking contribute to Compose
 but you're new to the project or maybe even to Python, here are the steps
 that should get you started.
 
-1. Fork [https://github.com/docker/fig](https://github.com/docker/fig) to your username.
-1. Clone your forked repository locally `git clone git@github.com:yourusername/fig.git`.
-1. Enter the local directory `cd fig`.
-1. Set up a development environment by running `python setup.py develop`. This will install the dependencies and set up a symlink from your `fig` executable to the checkout of the repository. When you now run `fig` from anywhere on your machine, it will run your development version of Fig.
+1. Fork [https://github.com/docker/compose](https://github.com/docker/compose) to your username.
+1. Clone your forked repository locally `git clone git@github.com:yourusername/compose.git`.
+1. Enter the local directory `cd compose`.
+1. Set up a development environment by running `python setup.py develop`. This will install the dependencies and set up a symlink from your `docker-compose` executable to the checkout of the repository. When you now run `docker-compose` from anywhere on your machine, it will run your development version of Compose.
 
 ## Running the test suite
 
@@ -84,15 +84,15 @@ Note that this only works on Mountain Lion, not Mavericks, due to a [bug in PyIn
 
 1. Open pull request that:
 
- - Updates version in `fig/__init__.py`
+ - Updates version in `compose/__init__.py`
  - Updates version in `docs/install.md`
  - Adds release notes to `CHANGES.md`
 
 2. Create unpublished GitHub release with release notes
 
 3. Build Linux version on any Docker host with `script/build-linux` and attach to release
 
-4. Build OS X version on Mountain Lion with `script/build-osx` and attach to release as `fig-Darwin-x86_64` and `fig-Linux-x86_64`.
+4. Build OS X version on Mountain Lion with `script/build-osx` and attach to release as `docker-compose-Darwin-x86_64` and `docker-compose-Linux-x86_64`.
 
 5. Publish GitHub release, creating tag
 

Dockerfile

@@ -14,4 +14,4 @@ RUN python setup.py install
 
 RUN chown -R user /code/
 
-ENTRYPOINT ["/usr/local/bin/fig"]
+ENTRYPOINT ["/usr/local/bin/docker-compose"]

README.md

@@ -1,5 +1,5 @@
-Fig
-===
+Docker Compose
+==============
 
 [![wercker status](https://app.wercker.com/status/d5dbac3907301c3d5ce735e2d5e95a5b/s/master "wercker status")](https://app.wercker.com/project/bykey/d5dbac3907301c3d5ce735e2d5e95a5b)
 
@@ -29,9 +29,7 @@ db:
 
 (No more installing Postgres on your laptop!)
 
-Then type `fig up`, and Fig will start and run your entire app:
-
-![example fig run](https://orchardup.com/static/images/fig-example-large.gif)
+Then type `docker-compose up`, and Compose will start and run your entire app.
 
 There are commands to:
 

ROADMAP.md

@@ -1,28 +1,26 @@
 # Roadmap
 
-Fig will be incorporated as part of the Docker ecosystem and renamed Docker Compose. The command-line tool and configuration file will get new names, and its documentation will be moved to [docs.docker.com](https://docs.docker.com).
-
 ## More than just development environments
 
-Over time we will extend Fig's remit to cover test, staging and production environments. This is not a simple task, and will take many incremental improvements such as:
+Over time we will extend Compose's remit to cover test, staging and production environments. This is not a simple task, and will take many incremental improvements such as:
 
-- Fig’s brute-force “delete and recreate everything” approach is great for dev and testing, but it not sufficient for production environments. You should be able to define a "desired" state that Fig will intelligently converge to.
+- Compose’s brute-force “delete and recreate everything” approach is great for dev and testing, but it not sufficient for production environments. You should be able to define a "desired" state that Compose will intelligently converge to.
 - It should be possible to partially modify the config file for different environments (dev/test/staging/prod), passing in e.g. custom ports or volume mount paths. ([#426](https://github.com/docker/fig/issues/426))
-- Fig recommend a technique for zero-downtime deploys.
+- Compose should recommend a technique for zero-downtime deploys.
 
 ## Integration with Swarm
 
-Fig should integrate really well with Swarm so you can take an application you've developed on your laptop and run it on a Swarm cluster.
+Compose should integrate really well with Swarm so you can take an application you've developed on your laptop and run it on a Swarm cluster.
 
 ## Applications spanning multiple teams
 
-Fig works well for applications that are in a single repository and depend on services that are hosted on Docker Hub. If your application depends on another application within your organisation, Fig doesn't work as well.
+Compose works well for applications that are in a single repository and depend on services that are hosted on Docker Hub. If your application depends on another application within your organisation, Compose doesn't work as well.
 
 There are several ideas about how this could work, such as [including external files](https://github.com/docker/fig/issues/318).
 
 ## An even better tool for development environments
 
-Fig is a great tool for development environments, but it could be even better. For example:
+Compose is a great tool for development environments, but it could be even better. For example:
 
-- [Fig could watch your code and automatically kick off builds when something changes.](https://github.com/docker/fig/issues/184)
+- [Compose could watch your code and automatically kick off builds when something changes.](https://github.com/docker/fig/issues/184)
 - It should be possible to define hostnames for containers which work from the host machine, e.g. “mywebcontainer.local”. This is needed by apps comprising multiple web services which generate links to one another (e.g. a frontend website and a separate admin webapp)

bin/docker-compose

@@ -0,0 +1,3 @@
+#!/usr/bin/env python
+from compose.cli.main import main
+main()