The project name should be configurable

[bfirsh]

Ideally in fig.yml (how do we have general config in there? maybe we need a top level services key?), but maybe in a separate .fig-project file or something.

[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.

[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.

[dnephin]

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

[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?

[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.

[wcarmon]

+2

[temirov]

👍

[kenylieou]

+1

[MadWombat]

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

[droidlabour]

+1

[jpringle03]

+1 I would definitely love to see this.

[deiucanta]

+1

[eugenesia]

+1

[edrzmr]

+1

[ameoba32]

+1

[igor-lemon]

+1

[vimalloc]

+1

[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.

[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