Volume driver reports as "changed" on second "libcompose up" attempt

[wagoodman]

Currently when attempting to run bring services up with libcompose, on the second attempt the Up command fails with Volume "node_modules" needs to be recreated - driver has changed.

The example docker compose file:

version: '2'

services:

  react:
    image: node:8
    networks:
      react-lan:
    command: yarn start
    working_dir: /app
    ports:
      - "3000:3000"
      - "4444:4444"
      - "9222:9222"
    volumes:
      - .:/app
      - yarn_cache:/home/node/.cache
      - node_modules:/app/node_modules

volumes:
  node_modules:
  yarn_cache:

networks:
  react-lan:

The issue looks to be here:

libcompose/docker/volume/volume.go

Lines 63 to 65 in 6bb86d5

	if volumeResource.Driver != v.driver {
	return fmt.Errorf("Volume %q needs to be recreated - driver has changed", v.name)
	}

It is assumed that there will be a known configured value for config.VolumeConfig.Driver, however, if no configuration is passed to this function, then no default value is provided (it remains an empty string):

libcompose/docker/volume/volume.go

Lines 88 to 93 in 6bb86d5

	if config != nil {
	vol.driver = config.Driver
	vol.driverOptions = config.DriverOpts
	vol.external = config.External.External
	}

Changing the volumes section does indeed fix the issue...

...
volumes:
  node_modules:
    driver: local
  yarn_cache:
    driver: local
...

...however, this is not desirable. Since it is very common to not require the volume driver to be specified directly in the docker-compose.yaml then it makes sense to only check for a change in driver only when comparing against a non-empty value.

Another solution to this would be to add a default to the config.VolumeConfig.Driver to the value of
local somewhere here:

libcompose/project/project.go

Line 318 in a86fb3c

func (p *Project) handleVolumeConfig() {

[xZero707]

I just encountered this with version 1.25.4 (From pip).
Any progress with this? It's an old issue that remains unsolved.

---

If you have encountered it, the workaround is available in reference posted by @frafra, just above this comment.

[thaJeztah]

@xZero707 this is the repository for libcompose, a go-implementation of a library for handling compose-files; I think you might be looking for the docker compose issue tracker; https://github.com/docker/compose/issues

[xZero707]

@thaJeztah I'm sure it's libcompose as I encountered error inside portainer/portainer container which utilized libcompose for stack deployment.

I agree, however that docker-compose from pip has nothing to do with libcompose. Sorry about the confusion I've created.
docker-compose on the host is not even used in a containers.

---

Also, to clarify; This bug is not in Portainer but in libcompose library as discussed here:
portainer/portainer#1989
timoknapp/rpi-nas#1

Anyway, libcompose is deprecated, so I suppose this discussion is pointless.