https://github.com/NixOS/nix/pull/31 may be relevant.
On 2015-12-28 11:10, Daniel Peebles wrote: > A few days ago, I proposed importing from a derivation [1] to save us > from having to manually manage autogenerated firefox/thunderbird > fixed-output derivaiton hash files and junk up the nixpkgs repository > with them. In response, Vladimír Čunát pointed out that nix-env would > currently force a download at evaluation time as a result of that > change, and that's undesirable. > > I see it as inevitable that we'll have to start importing from > derivations to make external package ecosystems more manageable. > Currently, haskellPackages is already eating up a large chunk of the > overall repository size, and as we start adopting similar automated > processes to manage other ecosystems, I see no way to keep the repo > size manageable. It also feels like a bit of an abuse of a VCS to be > putting autogenerated files in it, as we do today. Especially when > nix > is generally so good at doing that sort of thing for us. > > It seems like the main obstacle standing in the way of this pattern > is nix-env, given its habit (also unsustainable) of forcing the > evaluation of a large chunk of the packages expression. People have > expressed a desire to deprecate that sort of functionality, but I > don't know what sort of timeline such a change could be made on, so > I'm looking for ways to make it more manageable in the meantime. > > Does anyone have ideas on how to improve this? Or am I wrong about > things getting out of control if we don't? Are there other options? > > Thanks, > Dan > > > > Links: > ------ > [1] > https://github.com/NixOS/nixpkgs/pull/11319#issuecomment-167144900 > > _______________________________________________ > 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
