Restore ability to use named volumes

[JonathonReinhart]

Prior to #227, you could, as a not-officially-support feature map a named volume at a container path:

volumes:
  /foo: foo-volume

$ scuba --root --image debian:8.2 /bin/bash -c "echo yes > /foo/does-it-persist"
$ scuba --root --image debian:8.2 /bin/bash -c "cat /foo/does-it-persist"
yes
$ docker volume ls
DRIVER    VOLUME NAME
local     foo-volume

Since #227, this no longer works.

scuba: Config error: Relative path must start with ./ or ../: foo-volume

Reported #227 (comment) by @haboustak.

[JonathonReinhart]

From #227:

To avoid ambiguity with the old behavior, relative paths must start with ./ or ../.

And the v2.12 docs

To avoid ambiguity, relative paths must start with ./ or ../.

So I think we can easily restore the old behavior, using this required prefix to distinguish the two:

• If it starts with /, then it is a (host) absolute path.
• If it starts with ./ or ../, then it is a (host) relative path.
• Otherwise:
  • If it contains a / it is an error.
  • Otherwise it is a volume name.

NOTE: This only applies to the simple form:

volumes:
  /foo: foo-volume

In the complex form, the key is specifically called hostpath, so we shouldn't use that for a volume name. We should introduce another key -- mutually exclusive with hostpath -- perhaps just name since it is the name of a named volume:

volumes:
  /foo:
    #hostpath: foo-volume    # Error
    name: foo-volume

Test impact:

• test_volume_as_dict_missing_hostpath

See also:

• https://docs.docker.com/compose/compose-file/05-services/#volumes

[JonathonReinhart]

This is released in v2.13.0.

Enjoy your Go module caches!