Yeah longer term https://github.com/NixOS/nix/issues/520 can be of use, but for now normal fetchgit should be fine for the reasons Oliver mentions. 52 megs is something, but its only a compile-time dep, and in quite long term I hope things like IPFS means the hashes can be checked out incrementally.
> Honestly, though, IMO the nix/nixpkgs model of "determine the build exactly from the expressions" simply does not match the modern language-specific package manager model of "dynamically query a web service for the latest versions that meet my constraints". I think something leveraging nix-exec [2] might be a good short-term solution, and in the long term better management of impurities (at the expression level, resulting in still-pure *builds*) is needed. That incongruity is real, but the things like Stack, and Rust's Cargo's and Ruby's bundler's lockfiles convince me that perhaps those tools are a bit too non-deterministic for even more mainstream tastes. Not quite sure what the optimal setup looks like but I trust we will get there. Lastly, I mailed list before about this https://www.mail-archive.com/[email protected]/msg17048.html The big points are all already in this thread, but a few ideas on the details there. On Fri, Nov 20, 2015 at 6:42 AM, Oliver Charles <[email protected]> wrote: > On Fri, Nov 20, 2015 at 1:58 PM Shea Levy <[email protected]> wrote: > >> The problem with doing this with import-from-derivation is we still >> need the hashes of every tarball ahead of time (though that's much >> smaller than all of hackage, and we really just need the hash of the >> file that contains all the hashes in nixpkgs itself). If we have that, >> then we don't need to generate all of hackage every time, just the bits >> needed to build the specific requested package. >> > > What I would expect is that the "generate Nix expressions" Nix expression > - i.e., the thing that generates what is now hackage-packages.nix - would > have to be given known inputs. As far as I understand, hackage2nix simply > requires a checkouts of > https://github.com/commercialhaskell/all-cabal-hashes and > https://github.com/commercialhaskell/all-cabal-hashes. I would expect > that those could be provided by fetchgit, so updating the set of Haskell > packages simply requires Peter or other commiters to change the pinned Git > revisions. > > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
