4 ms·

This is pretty neat. I wonder if the idea could be extended more generally to "un-nixify" packages - i.e. replace references to the nix store with relative path

This is pretty neat. I wonder if the idea could be extended more generally to "un-nixify" packages - i.e. replace references to the nix store with relative paths. I can envision some applications for distributing packages for non-nix systems while still relying on nix to build them.

tadfisher 3y ago
There's an older attempt at a universal Nix bundler here: https://github.com/matthewbauer/nix-bundle https://github.com/matthewbauer/nix-bundle The flake schema has a "bundler" output that can point to an executable like this to bundle a flake's outputs for any supported target. Not sure about the state of the art, though.
- hamandcheese 3y ago
  My main gripe with this (and guix mentioned in a sibling comment) is lack of macOS support. I believe macOS support is a large part of why Nix is able to become so popular.
  - whateveracct 3y ago
    There's this, which does work on macOS https://github.com/3noch/nix-bundle-exe https://github.com/3noch/nix-bundle-exe I've never tried it out though.
mik1998 3y ago
Guix has this feature - guix pack https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....
- xyzzy_plugh 3y ago
  Not really. Guix only really targets Linux and it achieves relocatable packs by virtualizing the filesystem in a variety of extremely non-portable ways. You can do this with Nix as well, of course, Guix wins no points here. Neither supports non-absolute paths which is the crux of the issue.
xyzzy_plugh 3y ago
This can (and has) been done but sooner or later you step on a landmine package for which this is not possible (reliably patching the output), so you end up rebuilding (reliably patching the input) and now you're inevitably rebuilding the entire world. It would've been easier to just do that in the first place. That being said I've long suspected there is a happy middle ground where you hack at the problem from both sides. On one side you provide F(x) -> x' where x is an absolute path closure and x' is a relative path closure, for any supported subgraphs in the build graph. Then, for the rest, you rebuild from source using any transformed inputs you can. In other words, when you're evaluating x', if you have x in a cache already, and you can rewrite it, do so. If not, just build it from scratch. The problem is at some point you have to prove that both methods of producing x' result in the same exact output. This is not easy! However you can possibly prove it for any arbitrary closure by simply round tripping. For example, assuming the transform F(x) -> x' is cheap, and at some point you build x, which is almost guaranteed, then allow x'' == x and when you build x just try and retarget it anywhere, and then back again. This doesn't prove it actually works, but might prove that it's correct, which is acceptable to me. I haven't got far enough to try this out yet, of course. Be my guest!

tadfisher 3y ago

There's an older attempt at a universal Nix bundler here: https://github.com/matthewbauer/nix-bundle https://github.com/matthewbauer/nix-bundle The flake schema has a "bundler" output that can point to an executable like this to bundle a flake's outputs for any supported target. Not sure about the state of the art, though.

hamandcheese 3y ago
My main gripe with this (and guix mentioned in a sibling comment) is lack of macOS support. I believe macOS support is a large part of why Nix is able to become so popular.
- whateveracct 3y ago
  There's this, which does work on macOS https://github.com/3noch/nix-bundle-exe https://github.com/3noch/nix-bundle-exe I've never tried it out though.

mik1998 3y ago

Guix has this feature - guix pack https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack.html https://guix.gnu.org/manual/en/html_node/Invoking-guix-pack....

xyzzy_plugh 3y ago
Not really. Guix only really targets Linux and it achieves relocatable packs by virtualizing the filesystem in a variety of extremely non-portable ways. You can do this with Nix as well, of course, Guix wins no points here. Neither supports non-absolute paths which is the crux of the issue.

xyzzy_plugh 3y ago

This can (and has) been done but sooner or later you step on a landmine package for which this is not possible (reliably patching the output), so you end up rebuilding (reliably patching the input) and now you're inevitably rebuilding the entire world. It would've been easier to just do that in the first place. That being said I've long suspected there is a happy middle ground where you hack at the problem from both sides. On one side you provide F(x) -> x' where x is an absolute path closure and x' is a relative path closure, for any supported subgraphs in the build graph. Then, for the rest, you rebuild from source using any transformed inputs you can. In other words, when you're evaluating x', if you have x in a cache already, and you can rewrite it, do so. If not, just build it from scratch. The problem is at some point you have to prove that both methods of producing x' result in the same exact output. This is not easy! However you can possibly prove it for any arbitrary closure by simply round tripping. For example, assuming the transform F(x) -> x' is cheap, and at some point you build x, which is almost guaranteed, then allow x'' == x and when you build x just try and retarget it anywhere, and then back again. This doesn't prove it actually works, but might prove that it's correct, which is acceptable to me. I haven't got far enough to try this out yet, of course. Be my guest!