Target ports cannot be set to range when using long syntax

[Neirda24]

Converting

services:
    my-service:
        ports:
            - '20-21:20-21/tcp'
            - '40000-40009:40000-40009/tcp'

to

services:
    my-service:
        ports:
            -
                target: '20-21'
                published: '20-21'
                protocol: 'tcp'
            -
                target: '40000-40009'
                published: '40000-40009'
                protocol: 'tcp'

fails with :

services.my-service.ports.[].target: failed to cast to expected type: strconv.Atoi: parsing "20-21": invalid syntax

---

It seems published correctly supports ranges but target doesn't

[ndeloof]

short syntax 40000-40009:40000-40009 is actually expanded to 10 entries in long syntax:

            -  target: 40000
                published: '40000'
                protocol: 'tcp'
...
            -  target: 40009
                published: '40009'
                protocol: 'tcp'

long syntax actually reflect the Moby API used to create container, while the short syntax is just syntaxic sugar

[Neirda24]

seems this time teh long syntax isn't the way to go then. Will it be fixed ? I'd gladly help but have no knowledge of go.

[ndeloof]

it won't be "fixed" as the role for the long syntax is to offer detail about each and every exposed port, while the short syntax is just syntactic sugar, and offers a "range" syntax for convenience.
What's the reason you'd like to use long syntax with a range, what's wrong with short syntax?

[Neirda24]

I like long syntax because it usually provides more features than short one and also avoid bugs in some cases (volumes for example). I find it odd that for this particular use case it is better to use the short one as it is "lacking" a feature syntax from the short syntax. (I posted on slack first then I was told that it looked like a bug and should open an issue). If I was to try to implement it and post a PR. Could it pass or would it get a refused for reasons mentioned earlier ?

[ndeloof]

in this specific case, long syntax doesn't offer any additional option vs short one.
anyway, if you feel this is relevant, you can prepare a PR, but be aware the actual challenge is not to update the spec but to adapt https://github.com/compose-spec/compose-go