lewo

The image also depends on the nix2container binary since nix2container could change they way it generate images. When an image (with same inputs) is generated with 2 different nix2container versions,...

> We don't have to hash the binary itself. I didn't mean hashing the nix2container binary, i was only talking about the hash of the derivation which builds the nix2container...

Currently, `nix2container.buildImage` doesn't expose an attribute to specify the architecture. To support this feature, we would need to do two things: - expose an attribute in nix2container functions. The architecture...

@jmgilman No problem. I always like to see an issue being closed ;)

@blaggacao I would prefer to keep the current `contents` implementation because i think symlinking storepath is quite fragile. To avoid symlink issues, in `dockerTools.buildImage`, the `contents` closure exists in the...

Yep, we could add this argument if it is the best way to address your use-case.

@googlebot I consent.

fyi, I no longer work on this topic so i could not terminate this work :(

> Another potential solution that I think is worth exploring is using remote builders to build the OCI image. I think this is what @nktpro is doing. Currently, there are...

@jmgilman The remote builder builds the `image.copyTo` script (with all of its dependencies, ie the image itself) and your local deamon asks the remote store for the script `image.copyTo` which...