Advanced config file

[jderusse]

This PR improve the config schema by moving the services under a new top level node services.

version: 1.0
services:
  db:
    image: postgres
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    links:
      - db

Why ?

• Thank to the version property, the schema is extendable and we can keep Backward Compatibility
• We can add global parameters (like name, gobal env, global extends, ...)
• We can manage several versions of the schema (ie if a parameter is renamed in a future version).

What the difference with #463 ?

This PR does not mix service declaration and project configuration:

• More readable
• No collision between service's name and project key

I implement an usage of this new schema with an optional property project which replace the directory_name

version: 1.1
project: foo
services:
  db:
    image: postgres
  web:
    build: .

This should fix tickets #45, #745
Then we could extends this schema to fix #210, #318

note: The script does not break backward compatibility 😃 even if someone already use a service named project or .project or version or wathever

[csarrazi]

Bump

[yosifkit]

Ping @aanand, @bfirsh, @dnephin, @mnowster: any word on whether this is acceptable? Or reasons as to why not (besides the needed DCO sign-off)?

Having a project name in the yml (which is only part of this PR) would go a long way to help swarm integration since name conflicts occur often in multi-team environments.

[aanand]

@yosifkit The discussion over whether or not the project name belongs in the config file is #745. Until that's resolved, no PR which implements such a change is going to be acceptable.

[docteurklein]

I'd like to see a "services" entrypoint as well.
Not talking about the project name.
Nor the version constraint.
@aanand I think the project name being included or not is just a possibility.
I would simplify this PR to just allow a "services" key.

Once you moved the services from global, you're free too add more keys at the root of the file,
and avoid clashes with future potential keys (like metadata, project name, version, …).

It'd be cool to let the format open for extension.

For example, I'd like to add a "commands" key at the root of the file to enable a third party tool to read its config inside the compose yml file.

[michaeljs1990]

Anyway this can be modified to support a / separator instead of _ optionally with a flag something like...

version: 1.1
project: foo
services:
  delimiter: /
  db:
    image: postgres
  web:
    build: .

would build foo/db and foo/web. If it could be made to do that this would be a super helpful pr that would fix many issues that I have to write custom scripts for right now.

[dnephin]

Thanks for the contribution! Sorry it's taken a while to respond.

Our focus so far on the config has been to improve the validation and error messages. In the upcoming 1.5.0 release we've got a new jsonschema for handling the validation and much improved error messages.

I think we'd like to add a version to the schema, which may happen as part of #2113. If we're going to break backwards compatibility (or even just introduce a new format), we'd like to make a bunch of changes all at once (not just adding a version in isolation).

Sorry we weren't ready to make this breaking change when this PR was first submitted. Our configuration code has changed significantly since then, so I don't think we'll be able to merge this PR.