Preferred compose file name is now "compose.yaml" instead of "docker-compose.yml"

[bwateratmsft]

According to https://github.com/compose-spec/compose-spec/blob/master/spec.md#compose-file (and brought to my attention by @thernstig here), the preferred name for compose files is now "compose.yaml" instead of "docker-compose.yml". Currently none of our features recognize that as a compose file, so we should get things updated.

[ucheNkadiCode]

@bwateratmsft, Do you also believe this means we should also think about scaffolding our compose file with the name of "compose.yaml"? Sounds like it if that's what people are doing 🤷🏽‍♂️

[PavelSosin-320]

The docker app init creates the App project structure compatible with all Docker 19.03 and DockerHub standards. Do you really want to kill this Docker feature or only parameterize it?

[bwateratmsft]

@ucheNkadiCode I think @PavelSosin-320 is right, I'd rather not make that change for now. There are still older versions of Docker Compose in the wild and changing what we scaffold now would likely break them. I'd like to wait for "compose.yaml" to become more prevalent before we change.

[PavelSosin-320]

This is even not a PR, only loud thinking. Maybe, to solve all Spec compatibility issues altogether instead of many parameters and many checks it would better to introduce a single switch parameter "Backend-version" that switches everything: Docker, Docker-compose,API. Docker info tells to the user about the backend everything. The compatibility matrix is not something new in the software packaging.

[ucheNkadiCode]

@bwateratmsft, I hear you. So is there no way to do some sort of CTRL + Shift + P command, select "Change Language Mode" to set a compose.yml to a working Dockerfile type? Or would it be possible to simply add compose.yaml to the list of acceptable Dockerfile names for now? I think that is the main issue that there isn't really a workaround for naming your compose file differently than docker-compose.yml

[PavelSosin-320]

I suppose that this issue can wait at least few days until Docker-compose spec will be finalized and released.
It looks as in-process yet. See last commit date.

[bwateratmsft]

there isn't really a workaround for naming your compose file differently than docker-compose.yml

Sure there is, just rename the file.

[PavelSosin-320]

It is impossible to rename the file if there is an editor associated with the 'fixed" filename. Every respectable EDI opens the associated editor with all its machinery like Code assistance, Grammar check, and Context menu on the UI's select event, i.e. double-click.

[karolz-ms]

@PavelSosin-320 the Compose spec is a "living document". I doubt it will ever be "finalized".

[PavelSosin-320]

@karolz-ms And bad news came by mail: The Podman 3.0 will be released to fast ring soon. It will support Docke-compose Greate! But default Compose file name is docker-compose again, Ops!

[thernstig]

I am not sure what the problem is here. Let compose.yaml work with Intellisense (also give that file the proper icon - right now it is different from docker-compose.yml). And also allow docker-compose.yml (and yaml) as well for a long period of time.

[bwateratmsft]

I agree with @thernstig, all I intend to do right now is recognize compose.yaml/compose.yml for the purposes of intellisense and the compose up/etc. commands. Changing scaffolding right now is not a good idea given how new this change is to compose.

[PavelSosin-320]

@bwateratmsft I just got the notificatin and the inventation to test Podman 3.0. which will include Docker-compose support. The decision to include Docker-compose functionality means de-facto willing to kill Podman-compose project. It will lose its goal. B.Broude references the awesome compose project containing Compose-files ver 3.7Taking into account the popularity of RedHat's Kubernetes toolchain among Cloud application developers the combination docker-compose ver 3.7 has good chances to be accepted as the default.

[bwateratmsft]

Changing the icon to be the pink whale will require an update to this repo: https://github.com/microsoft/vscode-theme-seti

However, I don't think it's worth doing so at this time just for "compose.yaml" "compose.yml"; we plan to probably introduce a compose language ID / language server/ etc., which would make for a simpler way to implement the proper icon within that repo.

[PavelSosin-320]

Just for FYI: Podman embleme for future use

[thernstig]

@bwateratmsft Is there any issue to track the "icon" thing, somewhere you need to add this info that compose.yaml should get the whale?

[bwateratmsft]

@thernstig Sorta, I added it to the checklist on this issue: #2539

[bwateratmsft]

This is now released in Docker extension version 1.10.0.

[thernstig]

This is now released in Docker extension version 1.10.0.

Looking forward to the compose language ID / language server and thus icon updates, but I would recon that is a bit further away :)

[bwateratmsft]

This is now released in Docker extension version 1.10.0.

Looking forward to the compose language ID / language server and thus icon updates, but I would recon that is a bit further away :)

Yep, not sure how long. Icons might be tricky as they are actually defined by the Seti theme; I'm not yet sure what updating that would entail. I think we can show custom icons, and could maybe just copy the Compose SVG, but I still need to investigate further.