Compose: volumes vs volumes_from in v3 question

[whitecolor]

There is a case: 20 named volumes, one service installs dependencies on them, other multiple services use/attach those volumes, how this should be implemented in compose version 3?

version '2'

volumes:
  - node_modules
  - nested_node_modules
  - another_nested_node_modules
  # .. then another 20 common volumes

services:
   deps-install:
     volumes:
        - node_modules: /app/node_modules
        - nested_node_modules: /app/nested/node_modules
     # then 20 mappings to named volumes

  # then go multiple packages that use all the volumes 
  # that `deps-install` service installs dependencies on on
   package1-service:
       volumes_from: 
           - deps-install

   package20-service:
       volumes_from: 
           - deps-install 

What should be done in v3?

version '3'

volumes:
  - node_modules
  - nested_node_modules
  - another_nested_node_modules
  # .. then another 20 common volumes

services:
   deps-install:
     volumes:
        - node_modules: /app/node_modules
        - nested_node_modules: /app/nested/node_modules
     # then 20 mappings to named volumes

  # then go multiple packages that use all the volumes 
  # that `deps-install` service installs dependencies on on
   package1-service:
     volumes:
        - node_modules: /app/node_modules
        - nested_node_modules: /app/nested/node_modules
     # then 20 mappings to named volumes

   package2-service:
     volumes:
        - node_modules: /app/node_modules
        - nested_node_modules: /app/nested/node_modules
     # then 20 mappings to named volumes

To each service I need to add 20 named volumes mappings instead of one volumes_from?

[MichaelPereira]

Yes that's the way to go, as specified in the documentation:

• volumes_from: To share a volume between services, define it using the
  top-level volumes option
  and reference it from each service that shares it using the
  service-level volumes option.

I had to do that migration a few days back, and while it may seem counter-productive to remove that shortcut, in the other hand it forces to think about and explicitly declare volumes for each service. The volumes_from keyword hides a lot of complexity, as it also imported volumes declared in the docker images themselves, while now it's being exposed as part of the service definition and leads to less wondering where things are coming from.

[whitecolor]

Well really not productive for this case. And actually yaml format itself quite inflexible even though anchors allow to be more DRY. It seems that for more complex app structures and configurations it can be more productive and less error prone to have cofigs like docker-compose to be auto generated out of some more profound and DRY stuff.

[shin-]

Thank you for sharing your thoughts. Please remember that this is primarily supposed to be a bug tracker for docker-compose. If you want to discuss the Compose file format at a more abstract level, the forums might be a better avenue to do so.

[whitecolor]

How log is v2 format going to be supported by compose?

[shin-]

This is an open-source project. It will be supported as long as there are people willing to maintain and contribute to it.

[whitecolor]

I mean wouldn't it be deprecated soon in favor of new format versions.

[shin-]

See my answer here: https://github.com/docker/compose/issues/4513#issuecomment-289620945