3 ms·

When combining multiple packages, does the order matter? Does shell/git/htop give me the same thing as shell/htop/git?

n42 7y ago
since this is using Nix, I don't believe the order matters. each package installs its own isolated dependencies, there is no sharing between packages.
- eridius 7y ago
  Order doesn't matter to Nix, but images have ordered layers. After digging into the blog post, it sounds like the layers are sorted in a particular order, which suggests that the order in which you specify the packages doesn't matter. That said, I went ahead and pulled nixery.dev/shell/git/htop, and then pulled nixery.dev/shell/htop/git, and I actually got different results. I ran `docker info` on both images and diffed the results, and the layer lists were slightly different. I filed this as https://github.com/google/nixery/issues/38 https://github.com/google/nixery/issues/38.
  - tazjin 7y ago
    This is now fixed - the issue was basically that image manifests and config layers contain the image name, so if the name changes those layers will be replaced. The solution is to sort the packages in the name and return identical manifests. Docker doesn't seem to care about attaching names from registries that weren't in the config layer. There's a separate issue where Docker will re-download layers it already has because it doesn't just use the content hash for caching, but those layers will be identical. Working on figuring this one out ...
tazjin 7y ago
(Author here) The actual content layers (i.e. those containing Nix store paths) are going to be the same, but metadata layers (those containing the image name and the references to all layers) are currently going to be cache-busted. I'll look into getting that fixed - as long as Docker doesn't mind seeing a different image name than it requested in the manifest it shouldn't be an issue to return the metadata in a stable order.

n42 7y ago

since this is using Nix, I don't believe the order matters. each package installs its own isolated dependencies, there is no sharing between packages.

eridius 7y ago
Order doesn't matter to Nix, but images have ordered layers. After digging into the blog post, it sounds like the layers are sorted in a particular order, which suggests that the order in which you specify the packages doesn't matter. That said, I went ahead and pulled nixery.dev/shell/git/htop, and then pulled nixery.dev/shell/htop/git, and I actually got different results. I ran `docker info` on both images and diffed the results, and the layer lists were slightly different. I filed this as https://github.com/google/nixery/issues/38 https://github.com/google/nixery/issues/38.
- tazjin 7y ago
  This is now fixed - the issue was basically that image manifests and config layers contain the image name, so if the name changes those layers will be replaced. The solution is to sort the packages in the name and return identical manifests. Docker doesn't seem to care about attaching names from registries that weren't in the config layer. There's a separate issue where Docker will re-download layers it already has because it doesn't just use the content hash for caching, but those layers will be identical. Working on figuring this one out ...

tazjin 7y ago

(Author here) The actual content layers (i.e. those containing Nix store paths) are going to be the same, but metadata layers (those containing the image name and the references to all layers) are currently going to be cache-busted. I'll look into getting that fixed - as long as Docker doesn't mind seeing a different image name than it requested in the manifest it shouldn't be an issue to return the metadata in a stable order.