nix package manager integration

[jbenet]

ipfs and nix are well suited for each other. Discussed possibilities with @ehmry. Let's use this issue to figure out what to do. To start us off, some things that come to mind:

• come up with guidelines for installing packages from ipfs
• use ipget instead of wget in single packages to download things (requires ipget) (lowest friction)
• mirror/rehost the entire archive of builds (high friction but useful)

[ehmry]

Item two is pretty easy to get done, I have a simple skeleton that is waiting for ipget to drop into place, and then there will be a shell utility that takes a traditional url and spits out the fetchipfs { ... } code to cut and paste into a package specification.

Number three is a departure from how nix does things, but I think can coexist fine with the build farm system they have now. Nix packages come in the form a file or directory named xxx-name, where xxx is the hash of the the package inputs, and name is the package name, pmpc0i6i2kqvarjmbjwaxlb4h801jzfy-go-1.4.2 is an example. It is important to realise that this hash prefix does not identify the package content, it serves to create a unique name for a package based on the package inputs, its dependencies and build environment, so that different versions of a package with different dependencies can be installed side-by-side. There is another reason why it is not content that I will get to later.

I think that item three should be a matter of mapping package content to these package names, identifying these inputs with outputs. I don't know any of the implementation details, but this is what the nix build farm does. What we can do is map package outputs to the package input names using IPNS (correct me if I'm wrong on any of this). I think the process would be like this:

Alice

• Build package from source as usual, the output is /nix/store/07id4q-fooar-4.1
• Recursively add /nix/store/07id4q-fooar-4.1 to ipfs, yielding /ipfs/QmdWMhW
• Publish /ipfs/QmdWMhW to IPNS at /nix/store/07id4q-fooar-4.1

Bob

• Bob starts to build the same package as Alice, he has the same set of package inputs as Alice, so his package is also named /nix/store/07id4q-fooar-4.1
• The utility that starts the build process for this package looks up /nix/store/07id4q-fooar-4.1 in IPNS before it starts fetching the sources and building the package.
• IPNS yeilds /ipfs/QmdWMhW for the name /nix/store/07id4q-fooar-4.1, because Bob trusts Alice (I think this is how IPNS can work?)
• The build utility fetches and copies /ipfs/QmdWMhW to /nix/store/07id4q-fooar-4.1, the package is now installed, Bob is spared the scrolly text and can get back to work.

You may notice here that package is duplicated both at Alice and Bob, because it must exist at /nix/store, and also be present at some point in an IPFS repo. Nix requires that a package always be located at /nix/store, this is because of the strictly versioned depencies. If IPFS gets very strong file system intergration, then perhaps nix packages can be located under /ipns, /ipfs will not work because packages often must know their final location, and there no way to update an ipfs object with its location without implicitly changing its location. To me most expedient solution to duplication would be to archive and compress packages before adding them to IPFS, and then leave them unpinned.

[davidar]

👍

Also see https://botbot.me/freenode/ipfs/msg/53212515/

[jbenet]

btw, a basic ipget exists now: https://github.com/noffle/ipget thanks to @noffle

[hackergrrl]

I'm excited to see nix and ipfs get along well -- let me know if there are any ipget goodies you need!

[CMCDragonkai]

Just wanted to add:

We also need an IPFS source cache, not just binary cache. It would be an immutable source mirroring for all of our dependencies allowing reproducible builds from source (which is sometimes required as not all compiler flags are specified by default). I've had tons of problems buildings from source in Nix because upstream source urls break.

[ehmry]

It probably looks like I've given up on this, but I've been working on an alternate content-addressed store below Nix (and Guix I believe), and I will be attempting to build nixpkgs against it. If this works then the next steps would be to move to a multihash scheme and then try and figure out if its possible to push the store objects into the DHT without a second storage representation. Or maybe I've forgotten how the block chunking works, idk.

I can't give any estimates on time, there are a lot of things for me to do in between to make it work on my side.

[rrnewton]

@ehmry - was the alternate content addressable store because something about IPFS/IPNS didn't work out?

Also, about the trust model above -- is the idea that in practice we would trust a central Nix site to resolve a <hash>-package key into a content hash of build outputs?

This is discussed a bit in that #ipfs IRC log. "pierron" mentions that the build farm manifest includes signed content hashes. It sounds like the plan is to use the build farm as the central authority. One additional point is that since Nix isn't enforcing determinism currently, multiple observers that come up with (key,content-hash) pairs will come up with different hashes. That seems to also be an argument for a central authority (sample the nondeterminism once, consistently).

UPDATE: this point is addressed in more detail here: NixOS/nix#859.

[ehmry]

@rrnewton My motivation for an alternative store was one without a database, paths would be self-verifying and gargage collection would use something like bloom filers, but that project is on hold.

[vcunat]

Better late than later. Yes, I'd certainly start primarily with one central authority, which is what we de-facto have now. But it's only a matter of mapping .drv hash + authority key -> output hashes, and then people can simply trust any authorities they want.

[davidak]

We have the second item implemented: https://github.com/NixOS/nixpkgs/tree/master/pkgs/build-support/fetchipfs

@mguentner implemented a mirror, but encountered serious performance/traffic issues, concluded that IPFS is "not usable for production" with this use case.

Discussion in: NixOS/nix#859 (comment)