I want to try version 3 but I've immediately run into trouble with the lack of extends support.
There is an easy way around this which is to not use the YML for the master data and instead have it generated from another source that can manage things such as deduplication (templating it, or extending it putting back things like extends, etc).
However, the YML format is a bit like SGML is to XML and isn't so widely supported. The sheer majority of packaging or like systems out there will use JSON as support is ubiqitous and the syntax is simple.
Almost every language I might want to use comes with JSON as standard but YML is often a dependency that has to be installed separately.
I don't believe this would be a difficult thing to change and is generally unlikely to break anything.
Unless someone strangely has a .json file with the same name as yml, perhaps already porting one to the other and automatically looking for the file in the current directory now picks up the JSON and similar such issues. Docker Composer currently also ignores the extension (if you use -f x.json it will still be parsed as yml).
If docker already supports this (I have untested suspicions) it would be great to have documentation. There is also some inconsistency if you look at the documentation for docker compose files, it mentions that they are YAML but all the other file types around it such as credentials and logging are JSON based.
https://docs.docker.com/compose/faq/#can-i-use-json-instead-of-yaml-for-my-compose-file
@shin- Slightly related question: Is there a way currently to have the output of docker-compose config produce JSON, rather than yaml?
Reason being: It would be handy to be able to receive the JSON in other scripts without having to parse the yaml directly.
Maybe a --json flag could be added here?
Basic, useless example for the sake of discussion: docker-compose config --json | jq '.version'
@dsifford I'd say that's outside the scope of Compose. There's a bunch of command line tools available to convert YAML to JSON for those who need it:
Agree the tools are available, but for my particular use case it would be preferred to not have to leverage them if I don't have to -- especially so assuming you (compose) parse the yaml to ~json~ (Edit: likely, you're parsing it into a dictionary, but that can be easily turned into json using the json module in the standard library) already internally and then turn around and parse it back to yaml after validating with docker-compose config.
Is there a downside to just adding something like this in? I'd be willing to contribute a PR since this is admittedly something way near the bottom of the priority tree.
Is there a downside to just adding something like this in?
Code bloat for a feature that will be useful to 0.001% of the userbase is the main reason.
Fair enough 馃槉 Thanks for the dialog nevertheless.
@shin old issue but the 0.001% argument is clearly made up. In absence of any measurement it's indeterminate what format would be used more.
I would use both, but mostly JSON. For context many major devops tools like kubectl, gcloud, and aws all intentionally support JSON output, and it is useful in a variety of situations. FWIW I find it useful to support YAML as input (more flexibility in the config files) and JSON as output (better integrates with downstream tools).
If the YAML version fully supports JSON then that covers input. YAML wasn't JSON compatible when I first used it. Any output as YAML would be annoying for a lot of people though.
Most helpful comment
https://docs.docker.com/compose/faq/#can-i-use-json-instead-of-yaml-for-my-compose-file