You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
volumes: ["C:\data:/var"] with no top-level volumes: declaration is accepted by
Docker and refused by compose2pod, which is an over-rejection against the second rule
of docs/adr/0006-docker-rejection-parity.md: Docker accepts it, podman can express
it, so compose2pod should too. This is an unfinished parser, not a design position.
Measured against docker compose config v5.1.2:
Docker ACCEPTS. It special-cases a leading <letter>:\ so the drive letter
stays part of the source, resolving to {source: C:\data, target: /var}.
compose2pod REJECTS with refers to undefined volume 'C'.
The cause is the colon-based source extraction shared by parsing._classify_volume and emit.py's _volume_flags
(source, _, _ = volume.partition(":")). It splits on the first colon
regardless, so for this entry source is the single letter "C" — itself a
syntactically valid volume-name grammar match, not the unparseable string a naive
read of "doesn't match the name pattern" would suggest. Fixing it needs genuine
Windows-drive detection ahead of the split, in both call sites, not a
grammar-check swap.
Pre-existing since the named-volume reference check was introduced; not touched by
the tilde-bind-mount fix that discovered it. The conformance harness reports it as over-reject, so it stays visible rather than forgotten.
Revisit trigger: a user reports a compose file that docker compose runs and
compose2pod refuses — most likely this bind.
Not in scope. Two other over-reject cells the harness reports — sysctls: ["a"] and volumes: ["a"] — are not deferred parsers. They are measured
legitimate refusals (podman cannot form the flag), recorded in docs/adr/0006-docker-rejection-parity.md.
Reopening: the premise this issue was closed on does not hold.
It asserted "Docker accepts it, podman can express it, so compose2pod should too". The second half was never measured. Measured now, on podman 4.9.3 in the integration job (full table in #105):
-v 'C:\data:/var' exit 125 invalid option type "/var"
-v 'C:/data:/var' exit 125 invalid option type "/var"
-v '/tmp/C:\data:/var' exit 125 invalid option type "/var"
-v '/tmp/probe-src:/var' exit 0 (control)
-v splits a spec into at most source:target:options, so a colon inside the source pushes the target into the option slot. A drive letter cannot be carried through -v in any spelling, including one already resolved to an absolute path.
So under the second rule of docs/adr/0006-docker-rejection-parity.md this was a legitimate refusal all along, not an over-rejection — and #104, which acted on this issue, made compose2pod emit a flag podman rejects at exit 125. What was actually wrong here is the part the issue described accurately: the message. refers to undefined volume 'C' names a volume the document never contains, which is what made the verdict look like a parser gap rather than a ruling.
#107 reverses the acceptance and refuses the family with a message that cites podman. 0.4.4 was never tagged, so the acceptance did not reach PyPI.
Closing this again once #107 lands; the remaining drive-adjacent spellings stay in #105.
#107 landed: the family is refused with a message that cites podman instead of naming a phantom volume 'C'. Closing as a measured legitimate refusal, not as the accept this issue originally asked for. The remaining drive-adjacent spellings stay in #105.
Activity
lesnik512 commentedon Sep 20, 2026
Reopening: the premise this issue was closed on does not hold.
It asserted "Docker accepts it, podman can express it, so compose2pod should too". The second half was never measured. Measured now, on podman 4.9.3 in the
integrationjob (full table in #105):-vsplits a spec into at mostsource:target:options, so a colon inside the source pushes the target into the option slot. A drive letter cannot be carried through-vin any spelling, including one already resolved to an absolute path.So under the second rule of
docs/adr/0006-docker-rejection-parity.mdthis was a legitimate refusal all along, not an over-rejection — and #104, which acted on this issue, made compose2pod emit a flag podman rejects at exit 125. What was actually wrong here is the part the issue described accurately: the message.refers to undefined volume 'C'names a volume the document never contains, which is what made the verdict look like a parser gap rather than a ruling.#107 reverses the acceptance and refuses the family with a message that cites podman. 0.4.4 was never tagged, so the acceptance did not reach PyPI.
Closing this again once #107 lands; the remaining drive-adjacent spellings stay in #105.
lesnik512 commentedon Sep 20, 2026
#107 landed: the family is refused with a message that cites podman instead of naming a phantom volume 'C'. Closing as a measured legitimate refusal, not as the accept this issue originally asked for. The remaining drive-adjacent spellings stay in #105.