"Tags", "registries", "base images", "extraCommands"... no thanks
> ociTools
IIRC, this generates a runnable container (i.e. a directory, with accompanying config); not a container image, e.g. suitable for uploading to AWS ECS.
"Tags", "registries", "base images", "extraCommands"... no thanks
> ociTools
IIRC, this generates a runnable container (i.e. a directory, with accompanying config); not a container image, e.g. suitable for uploading to AWS ECS.
All of which are optional. It's just doing the same thing as your tar commands.
True, but they're dangerous enough that I'd still at least want a wrapper function which doesn't accept them at all.
> It's just doing the same thing as your tar commands.
Not quite: I came up with those commands by reading the OCI specifications.
In contrast, the output of the dockerTools functions does not quite follow those specifications, and appears to be more Docker-specific.
It uses dockerTools: https://github.com/NixOS/bundlers/blob/master/flake.nix
maybe a bundler can be added that uses OCI tools, thus providing such a wrapper and giving a nice CLI for it
Usually you wouldn't use any of that, unless you have some external organizational reason to depend on a base image. A typical image would just be:
dockerTools.streamLayeredImage {
name = "mything";
config.Cmd = "${mything}/bin/mything";
}I'll see if Nixpkgs is receptive to having such functionality, as a unification of what I've done with what exists in dockerTools (although I need to check that my employer's happy for it to be upstreamed first!)