Having an immutable content addressable storage for packages will really help maintain legacy applications. I got bitten recently by NPM wiping out a package completely which was a deep dependency of a number of legacy dependencies. Some software just doesn't need to be updated for years. On 01/12/2015 3:14 PM, "Ericson, John" <[email protected]> wrote:
> 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 > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
