Allow using docker-compose.yml.dist

[iamluc]

Having one docker-compose.yml file in a project can sometime lead to conflicts with others developers as we all need to adapt it to our needs (ports, volumes, environments, etc..).

With this PR, I suggest to allow compose to look at docker-compose.yml.dist if docker-compose.yml does not exist.
So the .dist file can be added to the VCS of the project, but can still be overrided by creating the file docker-compose.yml (excluded in the VCS).

This strategy is used for example by phpunit

[thaJeztah]

First impression: nice, I like it 👍

[dnephin]

Since this is a new convention, I think it's going to require some discussion.

My initial impression is that it might be good to support some kind of fallback (in addition to the "legacy filename" fallbacks we already do). I'm not sure what the filenames should be, or if we should actually make it configurable.

#745 proposed supporting a .compose directory which would allow us to include configuration for this kind of thing (meta-configuration).

If we don't allow it to be configurable, I'd prefer to keep the .yaml extension, but I'm not sure how that would look.

It's also worth mentioning that this can be accomplished pretty easily within a team or organization with a bash script wrapper and -f or COMPOSE_FILE

[iamluc]

It's also work mentioning that this can be accomplished pretty easily within a team or organization with a bash script wrapper and -f or COMPOSE_FILE

Sure, but wrappers are often a pain because they are differents on each projects: path/name, options, etc...
IMHO, a standard is better

[thaJeztah]

Yes, adding a wrapper is easy to do, but having it "officially" in compose will add to a standardized way to distribute a compose app (in stead of each project using their own way).

I think if a docker-compose.yml.dist is found, but no docker-compose.yml, Compose should output a warning, e.g. **WARNING** using 'docker-compose.yml.dist' you should create your own project-file ..

[aanand]

See #1987 (comment) for an alternative solution which also serves the multi-environment use case.

[mnowster]

Closing this as we now have the alternative solution done here #2051