Allow ENV to set multiple variables in one layer

[mingfang]

Currently each ENV command sets one variable and results in one layer.
Due the limitation of AUFS to 48 layers, it would be very helpful to allow ENV to set multiple variables at once.
Maybe like an array ENV ["key1=value1", "key2"=value2"]

[creack]

Marking as easyfix.
@mingfang Note that the 42 layer will soon get raised to 127 and might get remove altogether.

[pitex]

I will work on it

[crosbymichael]

I think this is a good idea. We do the same for EXPOSE and VOLUMES so I think ENV will be fine as well

[cpuguy83]

#3368

[mikz]

This would be awesome. It is really pity #3368 got closed.

[crosbymichael]

@mikz That PR was closed but we proposed a format that would be accepted.

[mikz]

@crosbymichael but the parser for that syntax it not yet implemented, right?

[crosbymichael]

Not that I know of but it would be easy to implement for this PR.

[mikz]

@crosbymichael what are the requirements for this to make it to 1.0?
When it would have to be implemented? Is it even possible?

[iwinux]

Is it related to #332?

[lox]

We're investigating implementing this with the changes introduced by #7461, is anyone else looking at it?

The syntax that @shykes mentioned was:

# Original syntax is not broken. Note the spaces in the value, they are properly supported
ENV FOO B   A   R  
# New shell-style syntax. Values can't have a space.
ENV foo=bar color=red answer=42
# Until we get around to interpreting special characters, they should be forbidden as regular characters to preserve forward-compatibility. So the following line should cause an error
ENV foo="bar baz" color=dark\ red

Is anyone opposed to that?

[cpuguy83]

@lox I would prefer to just make ENV (and other consecutive nop commands) happen in one commit. But IANTM

[lox]

Is there an issue related to specifically that issue @cpuguy83? I agree that would be a more worthy objective.

[tianon]

+1 I was thinking about exactly this today; now that we have a proper
parser, it should be "easier" to have it look ahead and coalesce multiple
"metadata" lines together into a single layer instead of many empty layers

[iwinux]

@lox the syntax looks much cleaner 👍

On the "special chars" part, what characters would be forbidden (besides " and \)?

[erikh]

Yup. :) The parser is completely independent of the evaluator, so there could be an optimizer step in between or something similar if we wanted.

On Sep 16, 2014, at 7:29 PM, Tianon Gravi notifications@github.com wrote:

+1 I was thinking about exactly this today; now that we have a proper
parser, it should be "easier" to have it look ahead and coalesce multiple
"metadata" lines together into a single layer instead of many empty layers
—
Reply to this email directly or view it on GitHub.

[andkirby]

Could someone tell since which Docker version should have this feature?

[cpuguy83]

1.4

[andkirby]

Thanks for quick answer! 👍