Why would someone use dockertools.buildimage over using a Dockerfile?

On ENV command it updates first one,
But when new stage starts or container runs it takes last one.
No merge or concat logic is applied.

Well, it’s an attribute in the image configuration. The spec is not very clear about what should happen if you specify the same variable multiple times:

Env array of strings, OPTIONAL

Entries are in the format of VARNAME=VARVALUE. These values act as defaults and are merged with any specified when creating a container.

I would interpret this such that the intent is for the variables to be “merged”, but the spec does not state what that means. I’d honestly consider opening an issue against the spec for this.

What the docker builder does or does not do with the ENV command is kind of irrelevant to the nix builder, here only the spec matters.

That, and whether the nix tooling allows you to create the output you intend - not being able to specify exactly the Env attribute you want can be considered an issue, and is worth working on upstream; you should probably open an issue. How docker uses that attribute is a docker upstream topic.

I think this PR should fix that issue for dockerTools.buildNixShellImage: dockerTools: add `CMD` override support to `streamNixShellImage` by commiterate · Pull Request #387173 · NixOS/nixpkgs · GitHub

With this, PATH is no longer set through the config.Env property in the OCI image configuration.

Instead, a Nix shell shim that’s now the default ENTRYPOINT prepends PATH.

I’m not too sure about dockerTools.buildImage though, but I think dockerTools.streamLayeredImage will be preferred instead once the PR is merged since it adds dockerTools.writeImageStream in order to support overrides on dockerTools.streamLayeredImage before writing out.

2 Likes