LegacyKeyValueFormat linter is noisy with very little practical value

[tianon]

At the risk of being a broken record, I still firmly believe it is a mistake to even attempt to deprecate the ENV key value syntax in favor of only supporting ENV key=value. Parsing the former is much simpler, and more in line with the way other Dockerfile instructions are parsed (and have been parsed historically). It is also much easier to generate from other code correctly and safely. As I noted on that other issue, if there are cases where the behavior of the former is ambiguous, that should be the thing we detect and warn about, not just trying to deprecate the entire syntax.

For the current linting rule, I would propose that it either be removed or somehow disabled by default, as it is causing unnecessary and noisy churn across the industry with very little practical benefit. 🙇 ❤️

Examples of unnecessary churn/noise:

• Update "ENV key value" format in README krallin/tini#226
• feat: Update Dockerfile ENV instructions to use = instead of whitespace as the key value separator nginxinc/docker-nginx#906
• Update Bonita base alpine image version to 3.20 docker-library/official-images#17136
• Supress LegacyKeyValueFormat warnings docker-library/ruby#465

[tonistiigi]

The syntax is deprecated and discouraged (since 2020). We should either remove the deprecation or we should warn. I don't see any point of deprecating but then still saying "it is fine, keep using it". If there are many Dockerfiles that use the deprecated syntax 4 years later, that is a sign that nobody follows the deprecation documentation, and if we want to change user's behavior, we need to tell them that they are using a deprecated command.

Personally, I tend to agree with the justification for deprecation. In addition to ambiguous cases:

• there shouldn't be a need to have multiple ways to define the same thing. Most people learn Dockerfile from reading other Dockerfiles, not by reading docs.
• space delimiters confuse users about possibility to define multiple env with the same command
• it is inconsistent with variable definitions in shell and export what most of Dockerfile commands are modeled after
• it is more consistent with ARG that doesn't support space delimiters

as it is causing unnecessary and noisy churn across the industry

It is only shown until you fix it one time. There is a #check=skip= directive in top of the file if you want to take a risk of using deprecated syntax.

@colinhemmings

[tianon]

Yes, I agree with your first point -- I argued against the deprecation back in 2020, and still do think we should reverse course on it because I still think it's a net negative.

"It's more consistent with ARG" isn't really compelling to me given that ENV came first and ARG was intentionally designed in a different way, which I also disagree with.

The way I see the "multiple ways to do the same thing" argument is no different than shell vs JSON syntax. It's a little hiccup for new users, but experienced users learn quickly. I do think there is value in having a warning for cases like ENV foo bar baz=buzz where it is clearly ambiguous, and I think that's a better use of a linting warning.

[tonistiigi]

The way I see the "multiple ways to do the same thing" argument is no different than shell vs JSON syntax.

But we did add a check for that as well. While non-JSON is allowed from CMD/ENTRYPOINT we now warn against it and ask user to only use JSON.

[tianon]

And RUN and VOLUME and COPY? (in all of which JSON vs non-JSON each have useful use cases)