Docker Compose roadmap

[aanand]

Per moby/moby#9694, here's the start of the Docker Compose roadmap.

[dnephin]

I believe this implies the config format will be changing as well (to support the version field) ?

[bfirsh]

LGTM

[thaJeztah]

Nice writeup. Some things I don't see mentioned;

• Integration with docker swarm
• What will the new binary be named? docker-compose or simply compose? Asking this, because in prior proposals I think there was a strong preference to use a Git-like approach to "decorate" docker with separate binaries. (I.e., being able to call docker compose, but have a separate docker-compose binary).

[bfirsh]

[bfirsh]

@thaJeztah Sorry, that was a bit of a hasty merge.

I will be submitting a subsequent PR to address some of those things.

[thaJeztah]

@bfirsh 😄 was just about to ask yeah. np. Let me grab the occasion to wish you, @aanand and @dnephin a very good 2015 (and family, friends and all others here, of course!)

[aanand]

The binary name is TBD, yes.

My problem with Git-style subcommands is that they're lengthy: imagine having to type docker compose, docker compose build, docker compose rm web etc. I'd much prefer a name both shorter and un-prefixed.

My first thoughts were dc or cmp, but both are standard Unix tools. Maybe dcm?

[thaJeztah]

I'd much prefer a name both shorter

Agreed - it is a tough one to pick right, docker compose obviously has the advantage that it "communicates" the relation with 'docker', but I understand your intent to keep it short.

Perhaps it should be docker compose, and install some aliases by default?

Perhaps really far-fetched, but what if "docker compose" would start an interactive shell? e.g.

$docker compose
$$ compose [myproject] > start web
Starting myproject_web_1…
$$ compose [myproject] > ps
Name Command State Ports
-----------------------------------------------------------------
myproject_web_1 /start.sh Up 0.0.0.0:49160->80/tcp

[gabrielgrant]

@thaJeztah Doesn't seem that far-fetched (cf. git annex shell)

[thaJeztah]

@gabrielgrant after writing it, I must say I actually liked the idea yes 😄 but not sure how easy it is to implement. Some thought should be given to UX and interaction with other processes (it may be cumbersome to have to "exit" the Compose-shell to for other tasks?). There should be a clear definition of what is possible inside the "compose shell", and what not.

[marksteve]

Are there also plans to port fig/compose completely to go?

[aanand]

@marksteve Nope - see moby/moby#9694. We're going to continue from the Fig codebase.

[bfirsh]

@marksteve here is some more papertrail about writing in Go: #94

@nathanleclaire and others have been working on it.

[marksteve]

👍