libcompose
libcompose copied to clipboard
docker
Support composefile v3
Compose v3 is pretty different since it's embedded in Docker now. Is the intention to keep Docker Compose as a separate entity as well, or will that be eventually be deprecated?
I'm also not sure if it makes sense to add v3 support to libcompose with aanand/compose-file already around.
cc @pradeepto @dnephin
@joshwget
Compose v3 is pretty different since it's embedded in Docker now. Is the intention to keep Docker Compose as a separate entity as well, or will that be eventually be deprecated?
It will still be supported by docker-compose version 1.10. v3 is a version of the format. The fact that it is supported by a command on Docker doesn't mean other project should not support it. Really I don't see why :sweat_smile:.
And the intention is to re-use compose-file to support v3 parsing somehow.
You will still be able to use docker-compose on a non swarm-mode docker engine (only the deploy part will not completely be implemented). docker/compose will support that so any library that is supposed to replicate docker-compose functionnality should support that too.
Hi @vdemeester
I'm starting to investigate on how to implement v3 of Docker Compose into libcompose.
When going through the code, it's hard to tell whats-what as there is a lack of comments. One particular question I have is the hack folder and the schema generation of v2 and v1.
Given a clean-slate, would it be better to implement via https://github.com/aanand/compose-file or adding v3 manually (since, like you said, there's not many differences other than deploy not necessarily being implemented since it's swarm-based).
This is also implemented in docker/cli
https://github.com/docker/cli/blob/master/cli/command/stack/deploy_composefile.go
@muka That's what we ended up using in https://github.com/kubernetes/kompose since we didn't get any feedback from @vdemeester on Version 3 of Docker Compose in libcompose. Perhaps one-day the efforts put towards stack could be back-ported / contributed to libcompose
@cdrage I am curious, have you directly imported the cli as package or ported the code. Can you share any relevant source? Thx
Hey @muka see: https://github.com/kubernetes/kompose/blob/master/pkg/loader/compose/v3.go
We ended up using the docker/cli library in order to parse the values into our own separate struct.
Would you put a comment on the project README.md indicating that github.com/docker/cli/cli/compose/* packages are the way to go? I've spent a few hours trying to crack this lib out, just to find that it might not be maintained in the long run, I believe docker guys are too busy to backport docker-compose cli to libcompose, for me importing docker/cli seems like a reasonable way to include docker-compose cli-like functionality in go code.
@andresvia I'm mainly trying to add support for v1/v2 in docker/cli, and then refactor this library to share the same code in some v2 branch or sthg 👼 (see https://github.com/docker/cli/pull/573)
the docker/cli (moby/cli) functionality is not easily resuable in libcompose as it of course renders whole compose files into "types" of the docker handler. This means "import"ing a massive amount of docker/moby code in as libraries into this project, and either converting them into classic libcompose types, or refactoring libcompose to use the docker/moby types. This means lots of work for Service, Network, Volume etc.
Basically, the new cli(ish) unmarshaling code produces objects used in the docker/moby project, not objects from libcompose.
I see Kompose is using docker/cli to parse v3 yamls, so probably community gave up with waiting for libcompose. https://github.com/kubernetes/kompose/blob/master/glide.yaml#L31
@devs-php sounds like the answer is a hard nope, might have to fork it yourself if you want v3+
