Reviving #6343 as it looks like the fix wasn't migrated to v2

[rijulg]

The issue in ticket (#6343) which was resolved in PR (#7762) appears to have been revived in docker-compose v2. To restate the issue, the driver_opts device parameter in volume configuration does not allow relative paths. I have tested it on docker-compose v2.3.3 and v.2.4.1 on Linux and WSL.

The fix was implemented as (https://github.com/docker/compose/blob/master/compose/config/config.py#L497) where relative paths were resolved to absolute paths before further usage.

I suspect that the relevant volume configuration in compose v2 is implemented here (https://github.com/docker/compose/blob/v2/pkg/compose/create.go#L1115) where we are passing the volume configuration as it is to docker client. This ends up creating volumes with relative paths that don't work. We need to implement the same fix as implemented previously, and resolve the paths to absolute paths before passing to docker client.

[JMLX42]

The $PWD workaround still works though:

    ui:
        driver_opts:
            type: none
            o: bind
            device: ${PWD}/../../../../../app/asset/html

[robertnisipeanu]

@JMLX42 $PWD workaround is still not cross-platform.
Eg. on Windows and WSL subsystem as the docker environment (the one recommended by docker), this error is thrown:
time="2022-05-08T21:06:08+03:00" level=warning msg="The \"PWD\" variable is not set. Defaulting to a blank string."

[ndeloof]

interesting.
From a Compose Specification point of view, driver_opts is expected to be an opaque attribute that can offer random configuration element for actual drivers, and the compose file format should not force a specific driver support (this is all container runtime implementation details here...) Adopting this behavior in the compose spec could be debated but would hardly be "vendor neutral" to match the initial intent.

Would make sense anyway... maybe we can just add some custom code for this purpose in docker/compose, wdyt @glours @ulyssessouza ?

[djherbis]

I don't think resolving paths client-side makes sense, it broke my setup in v1, causing #7900.
If you evaluate and expand paths locally, but then mount them remotely (remote DOCKER_HOST) there's no guarantee the paths are organized the same.

I suppose its fine if you are using a local docker client & server, but if you have a remote server, then you're working with two distinct filesystems.

[spreadpando]

I uncovered this issue when looking at docker-compose as a devops solution for our cross-platform team. This significantly complicates the use of compose as a tool for cross-platform devops. I'm only seeing this issue on Windows, but relative paths seem to resolve for MacOS (M1) and WSL2 for us.

[abauske]

Any updates on this topic?
This Problem is quite problematic for me as the only workaround I found is to take exact volume definition out of the compose file and only use external volumes. This means you have to create the required volumes using the docker volume command manually in advance.

[thaJeztah]

I don't think resolving paths client-side makes sense, it broke my setup in v1, causing #7900.
If you evaluate and expand paths locally, but then mount them remotely (remote DOCKER_HOST) there's no guarantee the paths are organized the same.

This was indeed the original reason for not resolving relative paths on the client side; docker (and docker compose) use a client-server approach, and while there's many scenarios where the daemon host (from where things are actually mounted) and CLI are on the same machine, there's also many setups where that's not the case.

That said; for the upcoming v23.0.0 release (currenty in "rc"), changes were made in the CLI to treat ./ and . as a special-case, to allow the current directory to be resolved on the CLI side (see docker/cli#1203, and docker/cli#3469), so it should probably be good for docker compose to follow the same approach (accepting ./ and .).

When using compose-files, there's still some ambiguity when using multiple compose files; something like compose-spec/compose-spec#248 would take the ambiguity away.

[ndeloof]

This has been fixed by compose-spec/compose-go#332

[tomasfejfar]

Does not seem to be fixed for me (see #6343 (comment)).

[DartVeDroid]

Hello @ndeloof,

I've just tested it in 2.15.1 (it does depend on compose-go v. 1.8.2) with "short" bind syntax, and I've got /c/Users/<path> in Source parameter, instead of the supposedly correct /mnt/c/Users/<> path.
As far as I understand, it just makes Docker to create directories /c/Users/<path> inside the WSL filesystem.