Proposal: make project-name persistent.

[thaJeztah]

By default, Compose bases the project name on basename of the directory compose
commands are run from. The project name can be overridden either by
passing a -p / --project-name option for each command or setting the
COMPOSE_PROJECT_NAME environment variable.

Using the --project-name option for each command is error-prone and for-
getting to pass the option when doing (for example) docker-compose up, will result in
another instance of the project being created under a different name or even
containers of a different project being replaced.

Using the COMPOSE_PROJECT_NAME environment variable is not useful when dealing
with multiple projects and can cause similar problems.

Proposal: make project-name persistent

To solve these problems, compose will save the name of a project to a file in the
build-context when the project is first started / built.

If a project-file is found, compose automatically uses the project-name from that
file and throw an exception if the user is trying to override the project-name
using the --project-name option.

File location

To allow further expansion of options, compose creates a hidden .docker-compose directory
in the "root" directory of the build-context. Inside that directory, a
project-name file is created, containing just the name of the project;

tree -a
.
├── .docker-compose
│   └── project-name
└── docker-compose.yml

Request for comment

There are a couple of things left to be discussed;

• Should the configuration-file be created automatically or should this
  be an explicit action by the user (e.g. docker-compose init --project-name=foobar)
• Should a command be added to remove the configuration file(s)? (e.g.
  docker-compose destroy)
• Compose allows specifying an alternative compose-file (--file) should the
  project-name also be applied to those? Should each compose-file get its own
  configuration?

And, in a wider scope;

• Is the project-name actually important? If not, compose could create a random
  project-name and store that inside the configuration. This would greatly reduce
  the risk of conflicting names with other projects running on the same server.

edit: renamed Fig to Compose

[bfirsh]

The project name isn't important. I like the idea of a random project name. Even better – could we generate a hash of the path to fig.yml and use that?

[dnephin]

I actually think the project name is pretty important. If you want to be able to do anything with the images in a CI pipeline, you need to know the project name to be able to retag them as something else.

Being able to override project name from an environment variables makes it easy to keep these unique, and predictable. I think no matter what happens, we need to support the override from environment variables.

I do like the idea of making the project name configurable from a file. I think a similar discussion happened in (#45). Having the project name in.fig/project-name seems like it will lead to a lot of really small files. I think it would be easier to just put it into the fig.yml itself (like it is suggested in #45, and one of the docker compose proposals).

What are the advantages of putting it in a separate directory and file?

[thaJeztah]

The reason for putting it in a separate file has a number of reasons, I'll try to explains my thinking behind this;

• To preserve the name that was used to start the project (i.e., --project-name=foobar), which can be different from the automatic project-name.
• Having multiple instances or versions of a project running on the same server, without them conflicting each other
• Or, in short, the .fig/project-name holds the name of that instance of the project.

Perhaps the file should be called instance-name or similar.

I do like the idea of making the project name configurable from a file

Although possible to do this with this proposal (by manually creating the project-name file), my primary use case was to have fig create the file in order to save the name that was used.

will lead to a lot of really small files.

True, the alternative is to skip the .fig directory, however, if additional things are needed in future, extra file(s) can be added without cluttering the root of your project. Git does it similar and I think it's a clean approach.

I think it would be easier to just put it into the fig.yml

I think both options can be complementary; use the name from fig.yml as the default if the name is not overridden by a flag or env-variable. Put the name that is actually used to start the project inside the .fig/project-name

Being able to override project name from an environment variables makes it easy to keep these unique, and predictable. I think no matter what happens, we need to support the override from environment variables.

Curious; how do you handle managing multiple projects? I.e. cd project-a && fig ps then cd project-b fig <something>?

Thanks for your feedback!

[dnephin]

Curious; how do you handle managing multiple projects?

I usually run fig from python-tox, which lets me set the environment, so I'm never really setting it in my shell. I also tend to use tmux, so I have a different shells for every project.

I think both options can be complementary

Cool, I agree.

I don't know if I'm sold on .fig/instance-name vs say .fig-instance.yml that could contain any instance specific overrides, but I think this is more of a minor point.

[thaJeztah]

Thinking of the project-name; If I understand your situation correctly, it's important to be able to have control over the images being produced, e.g. myapp:build12345, or also names of the containers? Just to get a "feel" for your situation.

My thoughts behind "random" project-names was that, as long as Fig is able to locate the containers for a project, nice-looking names aren't important. If I, as a user, can access a services' container via its service-name (e.g. fig stop web), the name of the actual container doesn't matter.

Even have been thinking that fig could keep track of containers by ID in a local storage inside the .fig directory (which could be a performance gain on machines with a lot of running containers). But that's really something for a separate issue.

Any thoughts on "implicitly" creating the 'project-name' file or "explicitly" via fig init? Perhaps if I have some time during the coming holidays I can experiment a bit (never coded anything in Python, so it will be really experimental :))

[dnephin]

it's important to be able to have control over the images being produced, e.g. myapp:build12345, or also names of the containers?

I guess image is the really important one, but being able to ensure that container names don't conflict is also really important on shared hosts. I see this proposal actually aims to deal with that issue as well.

But I do think that predictable names for containers are still important. I can think of a couple tasks where it's important for external systems (not just fig) to be able to identify a container by name:

• cleanup scripts to remove old containers, being able to identify what project created a container
• debugging/inspecting containers

Both of these are pretty easy right now because I already know what the container name will be. If I have to lookup a name it's somewhat more involved.

Even have been thinking that fig could keep track of containers by ID in a local storage inside the .fig directory

It is true this could be a performance gain, but I worry this is the wrong approach. Adding any persistent state to fig introduces the possibility of lots of bugs (that come along with state). I would much rather see this being handled by a labeling system in dockerd. If fig is able to just label containers and then query for all containers with that label , it keeps all the state in a single place (dockerd). I know there was talk of this at some point, I'm not sure if it's on the roadmap.

Any thoughts on "implicitly" creating the 'project-name' file or "explicitly" via fig init?

I guess implicitly would be more backwards compatible. I would like to avoid a fig init unless absolutely necessary. Instead of using the basedir, I could see it implicitly creating a project name of <basename>-<4 digit random id>

[frank-dspeed]

i can only say if fig starts generating random names now i will switch away from it because i run 1000+ containers on a single host and when i cant identify them by name any more its nothing for me.

[thaJeztah]

@frank-dspeed thanks for adding your use-case. If I understand correctly, you start your containers with fig, but "manage" them directly via Docker after that, making use of the naming convention that Fig uses?

Perhaps this is of interest to you as well: moby/moby#9882 - having meta-data would offer more ways to identify containers, not only their name.

[frank-dspeed]

ah yes i did such proposals a lot for example simply adding new filds and that but i ended in that case with simply adding a ENV and then i have that as costum fild i can parse it 🎯

[funkyfuture]

I think managing the unambiguity of the project name shouldn't be fig's responsibility.

when i understood your proposal correctly, the generation of a random name would render the FIG_PROJECT_VARIABLE and the --project-name-option useless. which is handy for 'templating' services.

[thaJeztah]

I think managing the unambiguity of the project name shouldn't be fig's responsibility.

I'm not so sure; Fig "silently" overwriting another projects' containers because if happened to be in a directory with the same name is sometimes nasty.

when i understood your proposal correctly, the generation of a random name would render the FIG_PROJECT_VARIABLE and the --project-name-option useless. which is handy for 'templating' services.

Following the discussion above, I think something like this would work

• If --project-name is provided, use that (and write/update the .project-name? Not sure)
• No --project-name is provided, but FIG_PROJECT_NAME is, use FIG_PROJECT_NAME (and write/update to .project-name?)
• None of the above, but .project-name is set, use .project-name
• None of the above; create a random name and write it to .project-name

[funkyfuture]

from someone's perspective who uses fig in scripts that take care of a name and pass it to fig, storing a name in the project (which is in my case rather a template) location makes no sense.

and still, i sensed it very intuitive that the directory name is used in the name of the resulting containers when i just ran fig up.
and let say, you look at docker ps -a, that won't be very helpful if it's filled up with random names.

would an option --random-name help in your situation?
beside that i think the ability to prepend some [a-zA-Z0-9_].* to reflect some namespacing would be useful for broader deployments.

[jderusse]

What's about using the fig.yml to store such informations ?

schema-version: 1.1
project_name: foo
containers:
  web:
    build: .
   command: python app.py
    links:
     - db
    ports:
     - "8000:8000"
  db:
    image: postgres

And to keep BC, in compose/project.py::from_config

@classmethod
    def from_config(cls, name, config, client):
        if 'schema-version' not in config:
            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)