bake(compose): allow dot in target name

[crazy-max]

follow-up #1018
fixes #1009

Signed-off-by: CrazyMax [email protected]

[tonistiigi]

I don't really like this. This is ambiguous to the --set target.args.foo and I also want to allow such selectors in HCL variable in the future. E.g. dockerfile = othertarget.dockerfile

Maybe for compose we could always replace . with _ after parsing and then also do that in bake arguments. Would that be an option?

[crazy-max]

Maybe for compose we could always replace . with _ after parsing and then also do that in bake arguments. Would that be an option?

Sgtm as internal naming but we still display . with --print right?

[tonistiigi]

Sgtm as internal naming but we still display . with --print right?

It might be better if we don't. Makes it clear that you can't use it in --set

[crazy-max]

Sgtm as internal naming but we still display . with --print right?

It might be better if we don't. Makes it clear that you can't use it in --set

I was thinking of users that are using --print programmatically but that's an edge case.

[tonistiigi]

I was thinking of users that are using --print programmatically but that's an edge case.

It shouldn't matter unless they start to parse the output and make some decisions about it. If they use it as input to other bake commands then all should work as expected.

[ciaranmcnulty]

I'd like this as currently I'm using version numbers in some target names and lack of . makes it painful.

Replacing with another char opens up a different set of ambiguities I think? What if I have targets called foo_bar and foo.bar?

It may make sense to escape dots in target names in the various places (e.g. --set 'version2\.0\.1.args.FOO=bar)

[tonistiigi]

What if I have targets called foo_bar and foo.bar?

If they are considered the same then they are merged.

[jedevc]

LGTM 🎉

[ndeloof]

fix is incorrect imho. If I have a compose file to declare foo.bar and foo_bar services explicitly, bake will merge those into a single target, which is not what I've asked for. Regarding #1011 (comment) I understand you want to keep . to be an operator, but then user should be warned about conflict, not silently ignored

[tonistiigi]

Detecting the conflict case sgtm