Nicolas De loof

Closing as obsolete. Requested feature is unclear how this would benefit docker compose usage

swarm does not use the compose specification (see https://github.com/docker/cli/issues/2527), so there's no reason it would be listed here for (un)supported features. Also, this specification was designed to be implementation agnostic....

Docker docs include some notes on the version require to use some recent feature (see for example https://docs.docker.com/compose/compose-file/08-configs/)

This indeed comes from swarm, as compose file v3 was introduced to support clustering mode - Docker Compose used `scale` attribute for this purpose. Compose Spec came later to reconcile...

AFAIK default installation has support for `bridge` (default) but also `macvlan` and `overlay`, and also allow use of direct `host` networking. This section should just refer to https://docs.docker.com/network/drivers/

@lonix1 what you describe here is a mechanism to watch for updated images, not local file. Please note the `develop` section is used for this feature, this is not intended...

I don't feel `depends_on.target: XX` to be more readable than `depends_on.service: XX`

> There is not currently a mechanism that allows us to explicitly use the image from one service directly in another build. While this is not defined by the compose...

@ciaranmcnulty sure, but this is what people use to rely on. Not doing so, your Dockerfile can't be built without compose, which sounds weird.

good point. Then using `service:` prefix with `additional_contexts`, just like we do for other cross-services relation seems a viable option.