Configure project name from the config file

[dnephin]

Resolve #45 and adds .project required for #318 and #210

Still needs documentation, opening PR for discussion regarding the top level key to use for this config (currently .project).

[huslage]

Why .project instead of just project?

[dnephin]

I'd like some way to denote that this is special, not a service. Using .project won't break existing fig.yml because that shouldn't be a valid name for a service. _project is another option.

[huslage]

Why would it break anything existing anyway? The option would just be
absent. project is just another top-level atom like a service name right?

On Wed, Sep 3, 2014 at 3:35 PM, Daniel Nephin notifications@github.com
wrote:

I'd like some way to denote that this is a special, not a service. Using
.project won't break existing fig.yml because that shouldn't be a valid
name for a service. _project is another option.

—
Reply to this email directly or view it on GitHub
#463 (comment).

Aaron Huslage
Solution Engineer
Docker, Inc
+1 919.600.1712

[thaJeztah]

Maybe add a global wrapper to distinguish settings like this from services, for example

fig-config:
    project: "myname"
    some-other-global-config:

[dnephin]

From the discussion in #45, I agree with @aanand that I'd rather not require a key at the top level. .project could change to fig-config though, or something else, as long as it's backwards compatible.

As for project not being backwards compatible, take this existing fig.yml:

project:
  build: ./path/to/project

When someone goes to upgrade they no longer have a service named project. While this is fine for a major release, I think it would make sense to add it initially in a backwards compatible way, and in the next major release change it to the "ideal" key. Upgrade should be pretty straight forward at that point.

[thaJeztah]

+1 for not breaking backward compatibility (although, chances are small that people used fig-config as a service name).

Not sure if this is valid in yaml, but how about using @ as a prefix, in stead of . (ie @project) ? My major dislike of a dot (.) is that it is easy to overlook and doesn't distinguish visibly from the services.

[dnephin]

I think anything with a dash or @ is fine because service names only allow letters/numbers right now.

[thaJeztah]

Well...from me, + 1 for @project, but of course, I'll leave the final verdict on this to the maintainers.

Thanks in advance for your effort!

[bfirsh]

fig.yml should really be called fig-services.yml. If we're going to have extra config, I think it should be in a separate file – something like .figconfig.

[huslage]

figconfig.yml?

On Thu, Sep 4, 2014 at 3:06 PM, Ben Firshman notifications@github.com
wrote:

fig.yml should really be called fig-services.yml. If we're going to have
extra config, I think it should be in a separate file – something like
.figconfig.

—
Reply to this email directly or view it on GitHub
#463 (comment).

Aaron Huslage
Solution Engineer
Docker, Inc
+1 919.600.1712

[thaJeztah]

Personally;

• I like the simplicity of fig, requiring just a single file, but if this really is an objection, having a project/config and services file is ok with me.
• It would be great if multiple config-files are allowed, e.g. for production, development but also for multiple developers working on a project. Each developer could then use his/her own project-name so that they can work on the same project on the same docker-host without conflicting (i.e. projectname-developerA, projectname-developerB)
• I've mentioned this in other issues (and it may be just a personal preference), but why hide the config file? It's nothing to be ashamed of? fig-config.yml seems nice to me.

[dnephin]

I'm happy there is more discussion about this. I'm really fine with any of these.

I also like having just a single config file. I think the multiple configs scenario is supported because you can just do fig -f <filename> (assuming we put the project name into the config file like in this PR).

I've actually run into another scenario where this is more critical. Running fig in test suites on jenkins. Every project is run in a worksapce directory (ex: job1/workspace, job2/workspace), so every image has the same project name by default. This results in test runs breaking other test runs when fig creates images and stops containers. Using fig -p <name> works for now, but not really as convenient.

[thaJeztah]

so every image has the same project name by default

+1 this my problem as well. All our projects have the same directory structure, so by default each project will be called src when doing fig up without extra handling.

[dnephin]

Change the top level key to project-config

[josephpage]

Looks to be a great idea.
I've made scripts to redefine FIG_PROJECT_NAME env in some cases, which are not easily portable.

[dnephin]

There is a different format being proposed for docker groups (https://gist.github.com/aanand/9e7ac7185ffd64c1a91a). If that format is considered stable, I'll discard this PR and add that support instead.

[zeevallin]

It this and #45 still on the roadmap?

I like the idea of having a .docker file to configure project specifics for docker configuration. It could work and be kept extensible through name-spacing by component name.

compose:
  project_name: "web"

To have a local override, using a similar approach to rspec could prove useful support a .rspec-local file #599 using a .docker-local file. This file could be ignored by your source control.

[Xe]

👍 I'd like to see this happen.

[mikehaertl]

+1 Some progress here would be awesome. I hit exactly the same problem of having multiple projects with the same directory structure. Using COMPOSE_PROJECT_NAME environment variable is tedious and error prone (you may easily forget it or "abuse" an existing terminal window to cd to another project).

@dnephin The PR doesn't merge anymore and I'm still not sure, what your final suggestion was. Maybe you could update the PR and give an example for how to use it? Just as an attempt to bring back some momentum into this old discussion.

[dnephin]

I'd still like to see this happen, but I don't think it will be this implementation. There's some good discussion in #745