The project name should be configurable about compose

[igor-lemon]

Right now we can use .env file with custom project name and set
COMPOSE_PROJECT_NAME=SOMEPROJECTNAME
It's not flexible but it's better than nothing.

[wcarmon]

+2

[jderusse]

The problem with your proposals, is that you'r mixing project configuration and service declaration. it's less readable and adding a keyword (projet or .project) can break backward compatibility.

I realy thinks it's time for docker-compose to improve it schema by adding a top level structure wich contains services.

containers:
  web:
    ...
  db:
    ...

With such structure, we'll be able to improve the schema like

schema-version: 1.1
project_name: foo
containers:
  web:
    ...
  db:
    ...

or

schema-version: 2.0
project: 
  name: foo
  default_env_file: ./bar
containers:
  web:
    ...
  db:
    ...

Notice the property schema-version which help us keep backword compatibilities with schema evolutions.
And to keep BC with current schema, in compose/project.py::from_config

    @classmethod
    def from_config(cls, name, config, client):
        if 'schema-version' not in config or not isinstance(config['schema-version'], basestring)
            config = {
                'schema-version': '1.0',
                'containers': config
            }
        dicts = []
        for service_name, service in list(config.containers.items()):
            if not isinstance(service, dict):
                raise ConfigurationError('Service "%s" doesn\'t have any configuration options. All top level keys in your docker-compose.yml must map to a dictionary of configuration options.' % service_name)
            service['name'] = service_name
            dicts.append(service)
        return cls.from_dicts(name, dicts, client)

If I've time, i'll work on a patch proposal in the nexts days.

[DrMeers]

Yes but it makes sense to allow the project name to be configured in the config file to avoid having to set it on the command line or environment?

[dnephin]

The project name is already configurable from command line or environment variable (-p or COMPOSE_PROJECT_NAME)

[MadWombat]

+1 maybe make it version: "3" or something

[jpringle03]

+1 I would definitely love to see this.

[aanand]

I don't want to give up top-level services without a fight. Perhaps everything other than service configuration could go in a top-level key with a special name:

PROJECT:
  name: myapp

web:
  ...

db:
  ...

[bfirsh]

.project:
  name: myapp

web:
  ...

db:
  ...

maybe

[bfirsh]

or maybe services is a reserved service name and you can either do

name: myapp
services:
  web:
    ...

  db:
    ...

or

web:
  ...

db:
  ...

depending on whether you need extra config. But that's a bit gross.

I think I quite like the idea of adding a top-level "services" key.

[sherzberg]

+1 on a special key like @aanand mentioned. I would like to do global environment variables here too :)

[djmaze]

+1 for top-level name and services keys. You could just make a new major release so backwards compatibility is not mandatory ;)

I also like the idea of global environment variables. So you could e.g. give credentials to a database container (for setting up the database & user) as well as all consuming services. Those would be defined in a top-level environment entry.

[thaJeztah]

Being able to specify the project-name manually (and not rely on the name of the directory) is quite important;

• using our standard project-structure, the most logical location for the fig-file to resort in will be named the same for all our projects.
• we're planning on using a shared docker host for our developers to work on. Multiple developers will work on their own instance of a project, so they should be able to provide a unique name for their instance of the project.

besides being able to specify the project-name inside fig.yml, fig should also take a parameter to override this, e.g. fig up -d --project-name=${USER}-my-project

[thomasf]

An alternative solution to having a special global key is to support two streams in fig.yaml.

Something like this:

project-name: something
---

db: 
  ...

app:
 ...

It might not be a good idea to attach semantics to location in the stream, I just wanted to throw it in the suggestion bowl.

[dnephin]

+1 for a single special key for non-service or "meta" stuff. This also came up in #210, and will be necessary for #318.

[dnephin]

@thomasf I'm not sure how many yaml parses support multiple streams. I tried it out with pyyaml and I got ComposerError: expected a single document in the stream.

[thomasf]

Its supported according to the docs by using load_all

http://pyyaml.org/wiki/PyYAMLDocumentation#LoadingYAML

[shuron]

What about several (related) projects in one fig.yml?
I wan't to manage them all in one fig. Cause to me fig define something like everything on one host or vm. So some kine of basic namespacing should be here. At least i wanna have a possibility to give containers custom names. ( run --name=custom).

[dnephin]

@aanand do you see the group.yml format in https://gist.github.com/aanand/9e7ac7185ffd64c1a91a changing much?

I'd like to add support for that format to fig so that users can migrate to the new format ahead of any docker release with this support (to make the transition smoother). That change should also resolve this issue.

If you think it's still likely to change, I can hold off until it's more stable.

[aanand]

@dnephin It should be considered unstable, so no adding support just yet. Input appreciated on the format itself - I'm actually somewhat unconvinced about putting the group name in the file, because it makes the whole thing less portable. Perhaps it should go in a separate, unversioned file.

[mikehaertl]

+1

Any news on this? There was an interesting suggestion by @jderusse here, which i like very much:
#745 (comment)

[yegortokmakov]

I have two projects that are using docker compose, one dependent on the other. For this use-case it will be great to have something like dependent projects:

schema-version: 2.0
project: 
  name: foo
  default_env_file: ./bar
require:
  project2:
    config: PATH | URL
    services:
      - serv1
      - serv2
    detached: true
containers:
  web:
    ...
  db:
    ...

I am posting there because it seems like relative to #1233
Does it makes sense? If yes, I will make it based on @jderusse code.

[dnephin]

This sounds a lot like #318

[phazei]

+1
It's a bother when dealing with many projects and many compose files to reply on "COMPOSE_PROJECT_NAME" or -p
Should go in the config.

[SonicGD]

+1

[dcosson]

+1

[pastuhov]

+1

[pahanini]

+1

[royingantaginting]

+1

[Filirom1]

+1

[mwr]

+1

[boedy]

+1

[koddo]

Hello. I know this is not a solution.
Right now I use this trivial script to unclutter the command line a bit:

#!/usr/bin/env bash

docker-compose --project-name whatever "$@"

Then:

$ docker-compose-whatever.sh up -d
$ docker-compose-whatever.sh logs

[jderusse]

Could works... until you manage dozen of projects

[koddo]

jderusse, I would write a line to make it take the project name from something like ./docker-compose-project-name. Just a quick and dirty fix until the option we all ask for is added eventually.

[koddo]

What about this?

#!/usr/bin/env bash

PRJ=$(head -n 1 ./docker-compose-project-name)
docker-compose --project-name "$PRJ" "$@"

[neilsarkar]

+1

[tkuben]

Any update on this? I would like a way to name the final image either via command line or via yml file.

[bachi76]

+1

[ChrisPearce]

+1 for being able to set this in the docker-compose.yml file

[alekbarszczewski]

+1

[dnephin]

Let's continue this in #745. The project name is configurable, now we just need a persistent configuration.

[temirov]

👍

[kenylieou]

+1

[droidlabour]

+1

[deiucanta]

+1

[eugenesia]

+1

[edrzmr]

+1

[ameoba32]

+1

[igor-lemon]

+1

[vimalloc]

+1

[richardbrinkman]

+1

[phoenixsampras]

+1

[jmthvt]

+1

[thaJeztah]

I'm locking the conversation on this issue; the -p / --project-name and COMPOSE_PROJECT_NAME options have been implemented over two years ago, and a follow-up discussion can be found in #745