On 17-04-25 07:26am, Benno Fünfstück wrote: > > > > The most interesting property is, that all dependency trees > > are linked together with symlinked, so they are cached by nix > > on a package level: > > https://github.com/Profpatsch/yarn2nix/blob/master/buildNodePackage.nix#L33 > > > Does this caching really gain us that much? The disadvantage of doing this > is that we have to maintain our own scripts for doing it, since upstream > does not support it.
Depends by who you mean by upstream. yarn: only the parser could break, but that’s easily fixable npm: they could change something in how packages work, but that’s unlikely. > phase 1: build a directory full of tarballs (just symlink the result of > fetchurl without unpacking) > phase 2: let yarn assemble the dependency tree (thus it will deal with > cyclic dependencies for us) Right now it takes around 4–5 minutes to unpack the tarballs for my project with node2nix. That is on every dep change. > This would only need a feature from upstream to use cached tarballs. npm uses the following algorithm: 1. resolve dependencies 2. move dependencies as far up the tree as possible to enable sharing 3. unpack the tarballs into the correct dirs 4. link the "bin" files into a .bin directory and the man files That’s it. We can skip step 2, because we don’t copy, but symlink already extracted packages (and filename length is not a problem on modern ext/btrfs/zfs) Step 4 becomes trivial once we skip 2. yarn is really just a 1:1 rewrite of node with lockfiles. I don’t know why people celebrate it so much, because it does exactly nothing differently apart from creating the lockfiles. Don’t even know why a rewrite was necessary. Maybe I missed something, but that’s the plan. -- Proudly written in Mutt with Vim on NixOS. May take up to five days to read your message. If it’s urgent, call me. _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev